Amplify-js: Auth.signIn throws error: AuthClass - Failed to get the signed in user – "No current user"
Describe the bug
Auth.signIn throws error: AuthClass - Failed to get the signed in user – "No current user"
To Reproduce
Steps to reproduce the behavior:
- Call
await Auth.signIn(<username>, <password>)
Expected behavior
I get back a valid user
What is Configured?
I have a Cognito User Pool configured and the username/password I'm trying to sign in with exists and is confirmed. If I replace Auth.signIn with Auth.federatedSignIn(), I am directed to the hosted UI, and upon logging in with the same credentials, I am directed back to the app, and everything works as expected.
The app client has Authorisation code grant flow enabled with allowed scopes: email, opened, profile.
Within the app, I am using authenticationFlowType: 'USER_PASSWORD_AUTH',
Environment
System:
OS: macOS 10.15.4
CPU: (8) x64 Intel(R) Core(TM) i5-8279U CPU @ 2.40GHz
Memory: 672.72 MB / 16.00 GB
Shell: 3.2.57 - /bin/bash
Binaries:
Node: 13.11.0 - /usr/local/bin/node
Yarn: 1.22.4 - /usr/local/bin/yarn
npm: 6.13.7 - /usr/local/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
Browsers:
Chrome: 80.0.3987.116
Firefox: 71.0
Safari: 13.1
npmPackages:
@babel/core: ^7.8.7 => 7.8.7
@babel/plugin-proposal-class-properties: ^7.8.3 => 7.8.3
@babel/polyfill: ^7.8.7 => 7.8.7
@babel/preset-env: ^7.8.7 => 7.8.7
@babel/preset-react: ^7.8.3 => 7.8.3
@babel/runtime: ^7.8.7 => 7.8.7
@react-native-community/eslint-config: ^0.0.5 => 0.0.5
@types/enzyme: ^3.10.5 => 3.10.5
@types/enzyme-adapter-react-16: ^1.0.6 => 1.0.6
@types/jest: ^25.1.4 => 25.1.4
@types/react: ^16.9.9 => 16.9.23
@types/react-dom: ^16.9.5 => 16.9.5
@types/react-native: ^0.60.25 => 0.60.31
@types/react-redux: ^7.1.7 => 7.1.7
@types/react-router-dom: ^5.1.3 => 5.1.3
@types/react-test-renderer: 16.9.1 => 16.9.1
@types/redux: ^3.6.0 => 3.6.0
@typescript-eslint/eslint-plugin: ^2.12.0 => 2.23.0
@typescript-eslint/parser: ^2.12.0 => 2.23.0
aws-amplify: ^3.0.16 => 3.0.16
babel-jest: ^25.1.0 => 25.1.0
babel-loader: ^8.0.6 => 8.0.6
connected-react-router: ^6.8.0 => 6.8.0
core-js: ^3.6.5 => 3.6.5
css-loader: ^3.4.2 => 3.4.2
enzyme: ^3.11.0 => 3.11.0
enzyme-adapter-react-16: ^1.15.2 => 1.15.2
eslint: ^6.5.1 => 6.8.0
eslint-plugin-jsx-a11y: ^6.3.0 => 6.2.3
file-loader: ^5.1.0 => 5.1.0
html-webpack-plugin: ^3.2.0 => 3.2.0
jest: ^24.9.0 => 24.9.0
jest-enzyme: ^7.1.2 => 7.1.2
metro-react-native-babel-preset: ^0.56.0 => 0.56.4
node-sass: ^4.13.1 => 4.13.1
query-string: ^6.13.0 => 6.13.0
react: 16.9.0 => 16.9.0
react-dom: ^16.13.0 => 16.13.0
react-native: 0.61.5 => 0.61.5
react-native-typescript-transformer: ^1.2.13 => 1.2.13
react-native-web: ^0.11.7 => 0.11.7
react-native-web-webview: ^1.0.1 => 1.0.1
react-native-webview: ^9.4.0 => 9.4.0
react-redux: ^7.2.0 => 7.2.0
react-router-dom: ^5.1.2 => 5.1.2
react-scripts: 3.2.0 => 3.2.0
react-test-renderer: 16.9.0 => 16.9.0
redux: ^4.0.5 => 4.0.5
sass-loader: ^8.0.2 => 8.0.2
style-loader: ^1.1.3 => 1.1.3
ts-jest: ^25.2.1 => 25.2.1
ts-loader: ^6.2.1 => 6.2.1
typescript: ^3.7.3 => 3.8.3
webpack: ^4.42.0 => 4.42.0
webpack-cli: ^3.3.9 => 3.3.11
webpack-dev-server: ^3.9.0 => 3.10.3
npmGlobalPackages:
npm: 6.13.7
FunkyLambda
All 16 comments
@FunkyLambda I couldnt reproduce your problem. Can you pase Amplify configuration (hiding endpoint details).
And if you can paste App client info as well (please also hide specific endpoint info)
aws cognito-idp describe-user-pool-client --user-pool-id <value> --client-id <value>
elorzafe
on 23 Jun 2020
@elorzafe I can confirm, same issue. Works totally fine from my local machine, but once I deploy to AWS Amplify in a staging environment, I get the error [ERROR] 17:30.884 AuthClass - Failed to get the signed in user No current user.
Here's my Amplify setup:
Auth.configure({
identityPoolId: process.env.VUE_APP_AWS_IDENTITY_POOL_ID,
region: process.env.VUE_APP_AWS_REGION,
userPoolId: process.env.VUE_APP_AWS_USER_POOL_ID,
userPoolWebClientId: process.env.VUE_APP_AWS_USER_POOL_CLIENT_ID,
mandatorySignIn: true,
cookieStorage: {
domain: process.env.VUE_APP_COOKIE_DOMAIN,
path: '/',
expires: EXPIRATION_DAYS,
// secure: process.env.NODE_ENV !== 'development',
},
});
And the result of the aws call you asked for above:
{
"UserPoolClient": {
"UserPoolId": "us-east-xx",
"ClientName": "xx-client-dev",
"ClientId": "xx",
"LastModifiedDate": "2020-07-28T18:57:25.378000-05:00",
"CreationDate": "2020-07-28T18:57:25.378000-05:00",
"RefreshTokenValidity": 30,
"AllowedOAuthFlowsUserPoolClient": false
}
}
Also interesting: all network calls to Cognito were successful (see below). I can even see the tokens and access key ID in the response.
ffxsam
on 29 Jul 2020
@elorzafe Ahh, changed from cookies to localStorage and now it works. So this appears to be a bug in that particular case. Strange that it works when I'm on localhost, though!
ffxsam
on 29 Jul 2020
@ffxsam are you able to store data on the cookies domain you are trying to use process.env.VUE_APP_COOKIE_DOMAIN?
elorzafe
on 15 Aug 2020
In this case, VUE_APP_COOKIE_DOMAIN=mysite.com (not the real domain). And the app is deployed via Amplify Console to v2.mysite.com.
ffxsam
on 15 Aug 2020
I am testing this now @ffxsam , I will keep you posted.
elorzafe
on 17 Aug 2020
@ffxsam Maybe I am doing something wrong, but are you using Amplify console environment variables (those supposed to be available only on build time). How are you configuring those variables on your app?
elorzafe
on 18 Aug 2020
@elorzafe They're just env vars in .env.<environment>. When Amplify Console runs yarn build --mode staging, it uses .env.staging to set the env vars and bakes them into the build.
ffxsam
on 18 Aug 2020
When I hard coded the domain amplifyapp.com on my app, it worked as expected however if I try to run the app on a different domain (localhost) I got the same error
elorzafe
on 18 Aug 2020
@elorzafe Cool (I think?) 😄 Does that mean you were able to replicate the issue? If not, I can take some time to set up a Vue reproduction for you. Let me know!
ffxsam
on 18 Aug 2020
Yeah, what I meant is the issue should be with what domain is configured for cookie storage, which I think the problem is that environment variable domain as where the app is hosted. Can you verify that value on runtime?
elorzafe
on 18 Aug 2020
Sure, let me take a look and I'll get back to you soon. Thanks!
ffxsam
on 18 Aug 2020
Super weird. It works now, and I don't believe I changed anything! Unless something else I've modified had an indirect effect. Very odd.
ffxsam
on 19 Aug 2020
This issue has been automatically closed because of inactivity. Please open a new issue if are still encountering problems.
![stale[bot] picture](https://avatars.githubusercontent.com/in/1724?v=4&s=40)
stale[bot]
on 27 Aug 2020
@elorzafe Ahh, changed from cookies to localStorage and now it works. So this appears to be a bug in that particular case. Strange that it works when I'm on localhost, though!
How do you change from cookies to localStorage?
camhart
on 21 Nov 2020
@camhart localStorage is the default option. So just make sure you're not specifying cookieStorage in the Auth options.
For what it's worth, I have no problems using cookies at this point. The only potential issue is that if your site is app.myapp.net and you also deploy PRs to something like pr-138.myapp.net, you will have double the amount of Cognito cookies and you could get an error about your headers being too large for your API to handle. So in my staging environment, I use localStorage:
Auth.configure({
identityPoolId: process.env.VUE_APP_AWS_IDENTITY_POOL_ID,
region: process.env.VUE_APP_AWS_REGION,
userPoolId: process.env.VUE_APP_AWS_USER_POOL_ID,
userPoolWebClientId: process.env.VUE_APP_AWS_USER_POOL_CLIENT_ID,
mandatorySignIn: true,
...(process.env.VUE_APP_ENVIRONMENT !== 'staging'
? {
cookieStorage: {
domain: process.env.VUE_APP_AUTH_COOKIE_DOMAIN,
path: '/',
expires: EXPIRATION_DAYS,
secure: process.env.NODE_ENV !== 'development',
},
}
: {}),
});
Related issues
cosmosof
·
3Comments
rygo6
·
3Comments
epicfaace
·
3Comments
josoroma
·
3Comments
leantide
·
3Comments
Most helpful comment
@camhart localStorage is the default option. So just make sure you're not specifying
cookieStoragein the Auth options.For what it's worth, I have no problems using cookies at this point. The only potential issue is that if your site is
app.myapp.netand you also deploy PRs to something likepr-138.myapp.net, you will have double the amount of Cognito cookies and you could get an error about your headers being too large for your API to handle. So in my staging environment, I use localStorage: