Is there a way to check if the user is confirmed at login? The response from userPool.signUp() includes a userConfirmed property, but I can't figure out how to determine whether the user needs to submit the verification code after an unsuccessful login attempt. The error response is just "Incorrect username or password." for unconfirmed users.
Determining user status during login is not currently possible in the beta today. We have heard this request several times and will prioritize it as a feature request.
Thanks. Is there any way at all to check if a user has confirmed their account post-registration, even if it's a separate request?
Unfortunately not from the client sdk, the only way to review a user's status is using the admin apis or through the console.
Is this still an on-going issue? We have recently ran into the exact same issue; unable to see the difference between an authentication fail and a successful authentication but un-confirmed account. Is there still no way to find out this confirmed status from client side?
Thanks.
Yes, there is still no direct way to check the user status from the client sdk's. We are considering to implement this as a feature request.
Thank you for the quick response! What would you say is the currently recommended way then to handle the process where a user doesn't confirm their account directly after a successful sign up, and instead closes the app, then comes back three days later and attempts a login?
I'd love to know the answer to that too. We're about to start development on a new project and wanted to use this service but don't feel comfortable moving forward without that feature. I know it's still in beta, but that's a big omission if there are no workarounds.
I thought of a possible workaround, but it's kind of clunky. In the User Pools console interface, there are triggers you can set up to call a lambda function. One is pre-signup, another is post-confirmation. Theoretically, you could keep track of which users have signed up but not yet confirmed their email by updating a database when a user signs up and when they confirm. Then, you could use that information to check when the server returns the bad username/password message if it's because the user is unconfirmed. The only problem is you wouldn't be able to tell if an unconfirmed user actually entered the wrong password. I also can't remember if there's a resend confirmation email feature.
Not a very elegant solution and I'm not yet desperate enough to actually spend the time implementing it, but I think it might work.
We came up with the same solution and the same attitude toward implementing it! Really hoping its a feature that gets implemented before we reach the point where we need to act on it and put in a hack fix.
At the moment we're just displaying a link (after an attempted login) under the error message of "Invalid Username/Password" with a message of "Have you confirmed yet?" which redirects the user to the validation screen using the username they attempted to login with.
The only major down side to any of these workarounds is that they enable users to spam and drive our usage costs up...not ideal.
+1
Hoping this is implemented soon.
+1
+1 Please :)
With this latest update, is this situation now possible to handle? There is a UserNotConfirmedException thrown by getSession, but I would have thought that it should be thrown by the authenticate function, because why would there be an open session for an unconfirmed or nonexistent user? Can anyone interpret this:
Two new exceptions added for getSession API: These exceptions have been added to accurately represent the user state when the username is invalid and when the user is not confirmed. You will have to update your application to handle these exceptions.
UserNotFoundException: Returned when the username user does not exist.
UserNotConfirmedException: Returned when the user has not been confirmed.
PasswordResetRequiredException: When administator has requested for a password reset for the user.
Yes it is. Now, when you try to authenticate and the user is not confirmed, we throw a user is not confirmed exception.
I can confirm it does appear to work. Note though that there are now four (as far as I've discovered - there may be more) exceptions returned:
UserNotConfirmedException - User tries to login but hasn't yet confirmedPasswordResetRequiredException - A password reset command has been issued on this users account.NotAuthorizedException - Password is incorrect (It will say Username or Password is incorrect in the message)ResourceNotFoundException - User not foundThe JSON object that is returned through the onFailure callback has a code property (of type string) so you'll want to do something like:
onFailure: function(err) {
if (err.code == 'UserNotConfirmedException'){
// Not confirmed
} else if (err.code == 'PasswordResetRequiredException'){
// Reset Password Required
} else if (err.code == 'NotAuthorizedException'){
// Not Authorised (Incorrect Password)
} else if (err.code == 'ResourceNotFoundException'){
// User Not found
} else {
// Unknown
}
}
There is also a message property on the object which will return some text to display.
Note that the user not found uses code ResourceNotFoundException not UserNotFoundException. If I've misunderstood anything please correct me! :)
Yes, that would be correct :).
I'm running version 1.9.0 and after registering a user, not confirming that user, then trying to authenticate, I get the UserNotFoundException. I was expecting UserNotConfirmedException.
I do see that user in the console and it does say UNCONFIRMED
OK I get the UserNotConfirmedException but when I try to get new verification code the app crash since the pool user has no username?
Came here from this discussion thread in the AWS Discussion forums.
Just wanted to voice my opinion that I'm not a fan of these response scenarios.
When calling cognitoUser.authenticateUser:
User does not exist. is returned.User is not confirmed. is returned.Incorrect username or password. is returned.From a security standpoint, this is not ideal as an attacker can just "poll" for valid user accounts and figure out if they're confirmed or not.
Although these errors are great for initial debugging of the application and/or troubleshooting errors a current user is having trying to login, these errors should be getting logged in CloudWatch and not getting returned to the client. In all of the above scenarios, the client should receive the Incorrect username or password. response. Developers should be setting the language of that failure to have the user double check their username and/or password, ensure that they did confirm/verify their account, and if they continue to have issues to contact support who can look at the logs to see the actual reason for the failure.
Is there any way to check if there is a successful authentication but unconfirmed account in the latest sdk?
Look at the exception in the callback:
cognitoUser.authenticateUser(creds, {
onSuccess: () => {
//do something
}
onFailure: (err) => {
console.log(err.statusCode)
console.log(err.code)
console.log(err.message)
}
}
Check if the err.code === UserNotConfirmedException or err.code === UserNotFoundException.
Unfortunately, this does not seem to work if you are using an email alias -- in that case, UserNotFoundException is returned if the user is registered but not confirmed.
See thread here:
#514 UserNotConfirmedException Vs UserNotFoundException
Just to echo, I completely agree with @bmoquist and @nwayve.
Very large security-hole, and many developers are likely not aware of this issue due to the inconstancy of error throwing.
Not to mention this has now been open for almost two years with no fix in sight?
@itrestian, can we please have this re-opened? It still seems to be an issue and #514 has been closed without any explanation (as far as I can tell).
Most helpful comment
I'd love to know the answer to that too. We're about to start development on a new project and wanted to use this service but don't feel comfortable moving forward without that feature. I know it's still in beta, but that's a big omission if there are no workarounds.