After successful registration and confirming with registration code, how do we make user auto login without having him to enter the login details again.

[shreynpatel274]

In our registration flow we do the following

1. Ask user to enter his details and do signup - which would make AWS call userPool.signUp()
2. Show a popup to enter confirmation code which is sent to his email -- to confirm the code we call cognitoUser.confirmRegistration()

Now once the registration is confirmed, we want to retrieve the user attributes and use them for his session. But it looks like the session is not created for the user after successful registration and confirmation.
userpool.getCurrentUser() - return null.

Is there a way to get the current registered user session, without having him login again?

[chetanme]

The only way you can do this is by doing the authentication for user behind the scenes.

From the SignUp page, you already have user's username and password in the app context. You can just use those values to create a new CognitoUser and then calling authenticateUser on the user object onSuccess of the user confirmation. On authentication success, userPool.getCurrentUser should return you the logged in user.

[hfougere]

can you explain further as to how to go about implementing login sessions in the web application? Should the cognitouser object/tokens be saved as cookies or local storage in the web browser and have them submitted with every request?

[itrestian]

At this point, it is not possible to return tokens immediately after the user has signed up and confirmed the registration. We are considering the change such that the user doesn't need to authenticate after registering and confirming registration.

As for the other question, the logins are stored in local storage upon authentication and cleared when signing out so retrieving them across pages should be handled by use case 16 in the Readme file.

[hfougere]

Thanks, I am now able to use the get session method to reauthenticate (use case 16). However its seems that this only works if i'm actively making these calls. If I do not call getsession for an extended period, the get session method does not reauthenticate and the session again becomes invalid. How can I extend the period that I can use getsession (or any other method to refresh the session) so the user will not have to reauthenticate for say 2 weeks, or a month? Is there a parameter I can use somewhere?

[jbailey2010]

That would be the access token expiring, which is expected. That duration is one hour, and is not currently configurable. The refresh token is used to get a new access token during that getSession call (if need be), and it's valid for a much longer time by default.

The validity of the refresh token can be configured from the Cognito console, if desired, but the access token is only an hour.

[hfougere]

Also, in terms of security... what's to stop someone from signing up a bunch of fake accounts since the userpool, client and identity pool ids are all easily accessible on the front end? It would be more work for them to confirm each of course. Is there a way to restrict where the requests are coming from (i.e ensure they can only be requested from my domain or my development ip address)?

[goldenbearkin]

Doing the authentication for user behind the scenes means you might have to store the user credentials somewhere (e.g. local storage or in-memory). This might introduce security vulnerability. User doesn't need to authenticate after registering and confirming registration is highly desirable and please have it as soon as possible.

[thrichards]

Adding a plus one to this request.

[hfougere]

In regards to my comment from Nov 21, 2016, is there any way to move this up in priority as more than just an enhancement? Anyone can call the admin confirm function on an account with the public id. Can we have a separate issue for this? At the very lease we should have a way to restrict api calls to come from specific domains or IPs we control.

[kevinwolfcr]

+1, I really need this feature on my app, for now I am temporary saving the password and that's super insecure.

[UlisesCabrera]

+1 to this request.

[scheler]

+1

[nishiltamboli]

This is extremely important. Its annoying to have them login again.

[jurriaanr]

+1 should not have been open for so long

[deblinaalways]

Please resolve the issue soon. Not able to get the session after confirm signUp.

[trecouvr]

+1

[deblinaalways]

I have resolved this issue after putting lot of time into it. Please follow the resolution steps mentioned below. This is for iOS integration.

1. Update pod 'AWSCognito' and 'AWSCognitoIdentityProvider'.
2. Sign up with userName, password and userAttributes. In the success response, acquire userSub from AWSCognitoIdentityUserPoolSignUpResponse. (In the earlier version there was a bug where AWSCognitoIdentityUserPoolSignUpResponse was not giving userSub.)
3. If result is not confirmed state, land into OTP validation UI Screen and pass the 'userSub' and "password", "userName" into it. (In the following steps, you will come to know why password has been passed.)
4. Call 'confirmSignUp' with the OTP you have received.
5. If it is success, get cognitoUser from pool.getUser("userName").
6. Call getSession("userName", password: "password"). (Do not call getSession() function which will land you up to Sign In UI Screen.).
7. In the success response 'AWSCognitoIdentityUserSession', you will receive 'idToken', 'accessToken' and 'expirationTime'. You can use it according to the need. getSession is useful when idToken gets expired.

The only problem what I faced is that I have to save the password locally (encrypt it and save.) to getSession with 'userName' and 'password' to avoid the sign in UI Screen to show.

I hope, this resolution gonna save lot of time for a time being for you guys until aws sdk gets updated where we don't have to save the password.
Thanks.

[youanswer]

+1 this feature is very much desired

[vedtam]

+1

[et304383]

Everyone commenting with "+1" should know that GitHub has a +1 reaction you can give to the original request which goes much further in terms of prioritizing an item as companies can do reports on issues sorted by +1 reactions, not comments.

[ghost]

+1

[deblinaalways]

+1

[et304383]

@lourdesmm90 @deblinaalways @shishiranshuman13 is this a joke? You're literally commenting with a +1 after a post about why +1 comments are useless and just create unnecessary emails to those watching the issue.

[deblinaalways]

@et304383 You only said, "Everyone commenting with "+1" should know that GitHub has a +1 reaction you can give to the original request which goes much further in terms of prioritizing an item as companies can do reports on issues sorted by +1 reactions, not comments." Your comments are contradictory dude!! Were you joking?

[shishiranshuman]

@et304383 If this bothers you so much I'll remove the comment and add a reaction instead. But please be polite in your comments.

[et304383]

Anyway, back to the issue.

https://github.com/aws/amazon-cognito-identity-js/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

@itrestian this is the most +1'd feature in your issue list yet it's been over a year with no enhancement. Why is this not at the top of the priority list for the Cognito JS team?