I'm trying to include a step for terms of use accepting during the login process in Identity Server, much like this question Adding Custom SignInResults to what's returned from a SignInManager<TUser> PasswordSignInAsync.
The problem is that the answer provided there is unsatisfactory because the screen we redirect to can be skipped as the user is already signed in.
Is there a solution where the whole sign in process is halted until an action is completed (similar to TFA flow)?
I think overriding the SingInManager class and implementing my own logic could be dangerous as I wouldn't be calling the base method anymore and thus would not benefit from updates down the road.
Related
I'm looking for some help with regards to the drop-in checkout integration.
https://developer-eu.elavon.com/docs/opayo/integrate-our-drop-checkout
In particular I'm following ‘custom flow’ example - see first code example for the Custom Flow section. https://developer-eu.elavon.com/docs/opayo/spec/api-reference#section/Custom-flow
In summary how can I programmatically determine if the sagepay 'card details' form which is injected into the sp-container (hosted in an iframe) is not valid for submission/tokenisation, when a call ‘tokenise’ link is used?
For example when the user has not completed all the required fields; Name, Card Number, Expiry or CVC.
I'm following the flow calling sagepayCheckout.tokenise() when the user clicks our 'Complete Payment' button (referred to as the tokenise link in the custom flow example).
NB: Implementation is part of a SPA app in my particular case I'm not submitting the (outer) form rather handling things using javascipt and calling the tokenise method.
Normally the onTokenise call back method is called on success or when wrong card details have been entered or merchantKey has expired. But when the injected sagepay form fails its own validity the onTokenise call back is never called.
NB: Due to browser security I can't check the state of the fields inside the iframe.
Ok some good points to note:
The sagepay form does feedback to the user about errors that required fields need to be completed.
And sagepayCheckout.tokenise() doesn't try to submit my (outer) form when these errors exist.
But there doesn't seem to be a programmatic way to know if the required fields need to be complete (or the onTokenise call back wont be called).
The main reason I need to know when the form is incompleted or tokenise has failed would be to re-enable our 'Complete Payment' button. Currently our button is disabled as soon as the user clicks it to prevent multiple clicks.
I am having this exact same problem. The only way I have been able to think of to get around this is to use the message event listener on the window. The sagepay.js library registers a 'message' event on the window object probably when the sagepayCheckout method is called.
Side note: this method is also poorly implemented as anything else that uses the window message event will cause the sagpay.js library to throw errors.
I think the only purpose of sagepay.js' message event hander is to resize the iframe window when its content changes. If you were to assume the content of the iframe will only change when validation fails you might be able use that to reset the state of your 'Complete Payment' button.
I would also suggest making a complaint to Opayo. This library is clunky and in desperate need of improvement.
Strange enough that I have to ask such a simple question.
I started automating with UFT and I suppose the correct way to check if for instance my login has worked is to add a checkpoint on the next page.
But how do I do that?
All info I get from google is on how to add an already existing checkpoint to may page. But I don't have any.
Here is how I go about automating:
I add manually the relevant objects to the object repository
I create parameters for my action
I create the code that does the steps on the page
one action per page seems to be fine for me
But in the Object Repository of UFT 14.53, there is no button to add a Checkpoint.
A workaround for me would be to just add another Object and check it's existence and forget about checkpoints. Until I hopefully get an answer here, I will try to do just that.
In UFT there are typically two ways to verify that things are working as expected.
Flow (implicit) - In order to verify that progress in the application is successful (e.g. login) one usually just keeps working with the app, assuming that if the previous step failed, the objects needed for the next steps won't exist and the test will fail due to ObjectNotFound errors
State (explicit) - In order to see that objects have a specific state, checkpoints are usually used. Checkpoints are typically added during a record session, I'm not sure if there's a way to add them directly to the repository. An alternative to checkpoints, which works better with keyword driven testing (no recording), is to use the built in CheckProperty method.
I'm using the Firefox permissions API documented HERE
I'm having a problem with the request method, wherein all of my permissions requests result in:
Error: permissions.request may only be called from a user input handler
You can produce this in firefox by debugging any addon or extension and entering browser.permissions.request({origins: ["https://google.com/*"]}) into the console.
I find it hard to swallow that a permissions request must always have a user input event callback in the parent stack trace. I'm using Vue.js, and my Permissions are due to user interaction, but my user interactions are decoupled from the events they trigger.
What counts as a user input handler?
Why does it work like this?
Is there a good work-around?
Is there a good work-around"
I'd like to add onto Andrew's answer with some code examples.
As it turns out, promise chains destroy the browser's notion of what is and isn't triggered by a user input handler. Take the code below, for example:
document.getElementById('foo').addEventListener('click', event => {
browser.permissions.request({origins: ["https://google.com/*"]})
})
This code works as expected. I originally assumed that it was Vue.js's unique event handling framework that was eating my "browser events", such as when you do <div #click="somefunc"></div>. This actually works just fine, as long as you put your permissions request in somefunc.
Now it gets fun. If you replace your permissions request with a promise that resolves and then does a permissions request, VIOLA!
Promise.resolve('foobar').then(foobar => {
browser.permissions.request({origins: ["https://google.com/*"]})
})
Results in:
Error: permissions.request may only be called from a user input handler
Why does this happen?
I'm going to guess it has to do with stack traces. Firefox can't detect that a permission came from a stack with a user input event at the root if the permissions request happens in a promise chain.
I consider this to be a pretty egregious design choice. My app is large (>4K LoC) and to keep it simple I rely on promise chains to keep the spaghetti away. This has crippled my ability to write clean code, and as a result, I've moved from asking for optional_permissions and then prompting the user for permissions only when needed to just being overly permissive at the time of installation.
GG, Firefox.
What counts as a user input handler?
A DOM event handler that corresponds to user input (e.g., target.addEventHandler("click", ...) or a WebExtension event listener that corresponds to user input (e.g., browser.browserAction.onClicked.addListener(...)
Why does it work like this?
Partly for basic UX (if a user is not directly interacting with an extension and a prompt for the extension suddenly prompts up, it can easily confuse them), but also to avoid clickjacking attacks where the prompt is put up at a carefully chosen moment when the user is likely to be expecting some unrelated prompt.
Is there a good work-around?
I think just organizing your code so that you request permissions from a user input handler is probably your best bet.
Recently, I have been working on a CredentialProvider in order to unlock automatically (the trigger can be any event, so let’s say the end of a timer) a Windows Vista (or more recent version) user session.
For that I read some useful articles on the subject, the change between GINA and this new architecture. http://msdn.microsoft.com/en-us/magazine/cc163489.aspx.
I think, like everyone in the process of creating a custom CredentialProvider, I didn’t start from scratch but from the sample code provided by Microsoft. And then I tried to change the behaviour (things like logging) in the different functions.
So in the end I can use the custom CredentialProvider, enter the SetUsageScenario methods but still I cannot reach the Set or GetSerialization method. From what I’ve understood in the technical documentation on CredentialProvider (still provided by Microsoft) theses two methods should be called automatically. Is there something I missed ?
Also, my original idea was to get an authentication package using Kerberos in order to perform an implicit user authentication. I got this idea by seeking information on other SO or MSDN threads like
Is this approach the good one ?
Thank you very much for your time answering my questions. Any clarifications are welcomed, even if they don’t directly resolve my problems :-)
First of all - you need to set autologon flag to true in your implementation of the ICredentialProviderCredential::SetSelected(BOOL *pbAutoLogon) and ICredentialProvider::GetCredentialCount methods.
Next, you need to call ICredentialProviderEvents::CredentialsChanged when your timer is hit.
LogonUI will recreate your credentials, and because autologon is set to true it will call your GetSerialization() method.
SetSerialization and GetSerialization functions are called from your provider by LogonUI. After user enters username/password and presses ENTER button, LogonUI calls GetSerialization function and provides a pointer, as one of the four parameters, that will point in future to CREDENTIAL_PROVIDER_CREDENTIAL_SERIALIZATION structure created and filled by you, and then this structure will be sent from LogonUI to Winlogon to perform authentication. I don't know how to make LogonUI to call GetSerialization from your credential provider code and as far as I know you can't call GetSerialization by your own because where will you pass your filled CREDENTIAL_PROVIDER_CREDENTIAL_SERIALIZATION structure if no one requested it, but only LogonUI can path it to Winlogon?
There is a document called "Credential Provider Technical Reference", there you can read some details about credential providers. In the Shell samples folder there is a strange folder called "Autologon", maybe it will help you! Good Luck!
I'm using a modified version of Felix Geisendörfer's SimpleAuth/SimpleAcl components that I've combined into a single Component, Simple_Authable.
I changed his startup() function to initialize() to not clutter the beforeFilter function in my app_controller.
One of the things that this component does is check who the active user is and if that user can't be found it either looks him up based on the primary User.id or uses 'guest'. Either way, the component uses $this->Controller->Session->write() to save the active user or guest information.
I'm also using Felix's Authsome plugin instead of the default CakePHP Auth component.
When I'm logging in, the active user is guest, obviously.
After I've submitted the form, the active user is still guest because the component's initialize() function is firing before everything else. Then, the Authsome plugin comes into play and validates my user as "root" and also calls $this->SimpleAuthable->setActiveUser($id, true); to force SimpleAuthable to update the active user information it is storing via $this->Controller->Session; Then I am redirected and my simple Session information and DebugKit's Session tab reflect that I am indeed the root user.
However, when I try to navigate to an 'admin' page, let's say /admin/users/index, lo and behold SimpleAuthable thinks I'm still a 'guest' user because when it performs a $this->Controller->Session->read() call to the key holding my user id, it is getting an empty response, i.e., the data stored on the previous page didn't persist.
Maybe there is something funky happening between Authsome & SimpleAuthable, but things look pretty straightforward and to my mind, $this->Controller->Session should be saving and persisting the data written to it.
So, I'm looking at refactoring all the calls to $this->Controller->Session and replacing them with $this->Session but first I wanted to throw this out to the community and see if anybody has seen anything similar and if so how did they resolve it.
Sincerely,
Christopher.
I found the problem... I'm also using Joshua McNeese's Permissionable plugin and I needed to disable it for the $this->Controller->{$this->userModel}->findById($id); in my SimpleAuthable component when I try to lookup the current active user.
Note to self: I would have caught this faster if I had some unit testing in place :(.