Issue changing password when reset on user pool

[cfsbhawkins]

So I have come across a state issue where, when I say reset password on the user in AWS, I get a PasswordResetRequiredException in the error when I call login with a username and a password. They also get an email with a reset key, same as forgot password workflow. The issue I am having is when I try and call Amplify.Auth.confirmResetPassword I get an error from Amplify that password reset was called before forgot password. I dont feel I should ask the user to call forgot password again just to get a second token so the state is correct.

Also IMHO, you should not be throwing an exception here, it should be passed along in next step on the result of a successful login.

[jamesonwilliams]

@cfsbhawkins Can you please show us the sequence of Auth calls you are making, in code? Can you identify the behavior your expect, versus the actual behavior at each step of your code? Thanks.

[cfsbhawkins]

I think it could be related to this bug a bit.

https://github.com/aws-amplify/aws-sdk-android/issues/1377

I switched out Amplify to AWSMobileClient call and it appears the mobile client is throwing the state exception. Exception: confirmForgotPassword called before initiating forgotPassword

So the flow is, log in to AWS console and reset a users password. They get an email with a code to change their password.

In my app a user logs in and then an exception is thrown that the password must be reset, so I route them in my app to the second part of forgot password since they have an existing code.

When calling Amplify.Auth.confirmResetPassword an exception is thrown that I did not call forgotPassword. This step should not be required as they already got a reset code from AWS when an admin triggered the reset on the pool.

[TrekSoft]

Hey @cfsbhawkins - yeah confirmResetPassword is only for a user who has called the resetPassword method.

Looking at the AWS Documentation it seems that it is intended behavior that even though the user gets a code already they have to request a new one... (see the bottom of this page here for the RESET_REQUIRED use case)

I definitely agree with you though that the throwing the exception and then forcing the user to request another code after they already got one is far from ideal so I'll update the status on this ticket to a feature request to handle this more gracefully.

[AntoEko]

Any news about this issue ? On the iOS lib, they don't have this behavior.

[sokarcreative]

+1, it looks like a missing feature and it makes no sense to call "resetPassword" when providing all information from url. We should be able to call a function like confirmResetPassword with an additional parameter "username".

[MilosKarakas]

Hi guys, are there any updates to this? This behaviour makes no sense to average user. I am currently developing an app for a high profile client, and this behaviour of the mobile client presents a huge setback and confusion to users.

Is there any timeframe when an update might be expected? Since we already have the data about username and the confirmation code, why are we forced to call forgotPassword always and initiate the password reset flow that way? What if we use amplify for more than one platform, and users initiates the reset from the web, but opens the reset link on mobile? Completely logical would be to send the code and email through a deep link and proceed with setting the new password.

Please provide updates if there are any. Thank you.

[gpanshu]

Hello, I apologize for the late reply to your question. If upgrading is an option for you I would invite you to try our V2 version of the Amplify Android SDK where the resetPassword and confirmResetPassword are not intended to be in the same session. The app can be closed and re-opened etc.

[github-actions[bot]]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see. If you need more assistance, please either tag a team member or open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.