When i use the UserInformationRecoveryService verifyConfirmation Code web service,it should get invalid after it is verified once.We are sending askPassword email after creating a user.User should be able to use that confirmation code only once.
Is there any config need to be modified.??
Currently confirmation codes retrieved at password reset will be only invalidated at successful password reset or at confirmation code expiration. Please follow details here.
As far as I remember, we had a plan to make this configurable, but from the jira I can't find that we have implemented it or not, so most likely we haven't done that yet.
Related
I have a flask application running on a production environment, and one of the user requested a password reset, which sent out an email to them with a link back to the site for resetting the password.
That email got shared with a third-party probably, and the link got exposed. Now the reset request is being spammed from multiple IP addresses. There is a timer I set using the SECURITY_RESET_PASSWORD_WITHIN config parameter to 30 mins and I can see that it does work as intended, the link is invalidated and throws an error saying the link has expired.
But the default behavior of the Flask-Security package is to re-send the reset email to the user if the token has expired when doing a GET request to the reset page with the expired token. So someone can keep spamming that expired link using
GET /reset/token_id
and the user keeps getting sent reset emails.
What is the correct way to handle this situation?
Once the user changes their password, those tokens should be viewed as 'invalid' and then not send emails any more.
I'm working on a scenario when the user never got (or lost) the registration email with the temporary password. Now common sense will drive the user to the "forgot password" process. But here, he'll get an error saying "User password cannot be reset in the current state." What now? I'm trying to find a way to re-send the email with the temporary password FROM the client-side.
I know there's the option of AdminCreateUser with "MessageAction": "RESEND" but that involves the back-end and I would prefer keeping this logic in a component in client-side (where the rest of the authentication logic already is).
I've been trying with the method "resendConfirmationCode" of CognitoUser but I get a "NotAuthorizedException" error with the message "Can't resend confirmation code for this user"
Every other post I've read regarding this very scenario ultimately proposes the AdminCreateUser option without even trying to explain why "resendConfirmationCode" doesn't work.
Even if it can't be done, any help with this issue will be greatly appreciated.
I am following this guide to allow the users to reset the password using email. The problem is when the user requests "password reset link" for multiple times, the old links generated are not invalidated. (Password can be reset using either the latest link or old links).
Is there any parameter I can set to invalidate the old links?
There is a property file called identity-mgt.properties which you can find in the /repository/conf/identity/ directory.
In this property file, there is a property called Notification.Expire.Time which you could use to set the confirmation code expire time in munites.
Notification.Expire.Time denotes the expiration time of the confirmation code. Even in a notification recovery scenario a confirmation code is generated. If notification is done via email, the link sent to the user for verification will include the confirmation code. Therefore, once the user clicks that link, the confirmation code will be verified. Thus, you can use this property to validate the link.
Currently, generated confirmation codes will invalidate only once user change his password successfully. So as you have mentioned user will be able to recover his password using any confirmation code he has retrieved. And when user successfully change the password, all the confirmation codes generated before that would be invalidated. This is the default behaviour for now and we don't have a configuration to change that.
We are using WSO2 IS 5.0.0 and are implementing the user recovery process. We have noticed that when the user gets the confirmationCode from the email sent from executing the soap call "sendRecoveryNotification" in UserInformationRecoveryService that the confirmationCode is only valid for one attempt.
Is there a way to set the confirmationCode to remain valid until the user successfully updates their password as well as other similar operations requiring WSO2 generated confirmationCodes?
This is fixed with [1] and will be available in IS 5.1.0-Alpha-2
Isura
[1]https://wso2.org/jira/browse/IDENTITY-3175
I'm currently designing a solution with this pretty standard pattern:
1 web-app using Django (it hosts the one and only DB)
1 client mobile app using AngularJS
This client app uses a REST API (implemented on the Django Server with Tastypie) to get and set data.
As a beginner in these architectures, I'm just asking myself where the logic should go and I'd like to use a simple example case to answer my concerns:
On the mobile client App, a client is asked to subscribe by entering only an email address in a form.
a) If the address is unused, inscription is done (stuff is written on the DB).
b) If the address is used, an error is raised, and the user is asked to try again.
What is the workflow to perform these simple operations?
I'm asking for example how to compare the entered e-mail address in the mobile app with the existing e-mail adresses in my DB:
Should I GET the list of all email adresses from the server, then perform the logic in my client app to state if the entered address already exists ? This seems really a bad way to do because getting lots of elements isn't performant with web services, and client should not be able to see all email adresses.
Should I send the entered e-mail address to the server and let it make the comparison? But if yes, how am I supposed to send the data? As far as I know, PUT/POST are made to write in the DB, not to just send data to server to analyse it and proceed some logic.
I have the feeling I am clearly missing something here...
Thanks a lot for help.
PUT and POST are designed to be used to create and update resources. The server may or may not have a database behind it. It might use a local filesystem, or it might handle anything in memory. It's none of the client's business. It is certainly common to have business logic on most servers which provide APIs.
Use PUT/POST to send up the email address to the server. The server checks to see if the email address is (a) valid, and (b) allowed. If it fails either check, return a relevant response to the client as documented in the RFC. I would go with 403 Forbidden, which indicates a problem with the data being sent up to the server. Use the entity in the response to detail what the problem was with the request.
I had done similar thing in a angular web app,
I have disabled the submit button, and added a check availability button beside the email field.
I have send the email to server and checked if it already exist and got the result to client,
then asked the user to enter an alternate email if not valid or enable the form's submit button
Alternatively
when the user leaves the email field, You can send the email to a service that validates the email, and get the response, and show a message that this email already exist and disable the submit, or enable the submit button otherwise