Closed MarekBodingerBA closed 3 months ago
israx
commented
8 months ago This exception happens usually when there is a domain miss match after the user is being authenticated. For instance,
if your cookies are configured with the http://www.a.com/ domain, and your users are authenticated on the http://app.a.com/ domain.
Will your end-users always be authenticated into one domain ? Or is this domain changing based on some scenarios ?
MarekBodingerBA
commented
8 months ago @israx Thank you for the response. I checked the logs, all the users are attempting to sign-in on:
https://konto.bratislava.sk/prihlasenieThis doesn't differ in any way from successful logins. We don't use any other domains and there are no dynamic scenarios.
HuiSF
commented
8 months ago Hi @MarekBodingerBA Do you have any data from the logs that what browsers were these users using?
MarekBodingerBA
commented
8 months ago @HuiSF Nothing suspicious from my side, I extracted the related fields from the logs:
HuiSF
commented
8 months ago Thanks @MarekBodingerBA and yes I don't see anything that is abnormal.
When you are saying you were not able to reproduce this issue, did you try to login using the credentials of a real user who was not able to login?
There could be something that causes the library token parsing logic to fail while retrieving authentication tokens from the cookie store (per {ssr: true}) right after a successful sign-in. Could you provide the following information?
username value of a user who was not able to sign in due to this issue, it should be the value of the user name column seen in the Cognito console
mpinter
commented
8 months ago @HuiSF hi. I'm also one of the maintainers of this project, filling in some of the data requested:
2bf74b91-22f2-46c4-b342-74ede104a7e4 . We can probably get more if needed.custom:sign_in_at property, adding code below:import AWS from "aws-sdk";
export const handler = async (event) => {
console.log(event);
const userSub = event.request?.userAttributes?.sub;
if (!userSub) {
throw new Error("No userSub found in event.request.UserAttributes");
}
const cognitoIdentity = new AWS.CognitoIdentityServiceProvider({
accessKeyId: process.env.AWS_COGNITO_ACCESS,
secretAccessKey: process.env.AWS_COGNITO_SECRET,
region: process.env.AWS_COGNITO_REGION,
});
await cognitoIdentity
.adminUpdateUserAttributes({
UserAttributes: [
{
Name: "custom:sing_in_at",
Value: new Date().toISOString(),
},
],
UserPoolId: process.env.AWS_COGNITO_USERPOOL_ID,
Username: userSub,
})
.promise();
return event;
};edit: today we're not relying too much on this extra attribute, it helped us with user migration some time ago - so if there's a chance this will help the issue, we can just turn this trigger off - in fact, I'll do it right away to collect some data on this
cwomack
commented
8 months ago Thank you @mpinter for the extra context here. We'll try to reproduce this on our side then, but if you find a way to more reliably reproduce then let us know!
CC: @MarekBodingerBA
cwomack
commented
8 months ago @mpinter and @MarekBodingerBA, are either one of you able to join us on a call to demo/reproduce the behavior (if possible) and allow us to review your Cognito setup? So far, we have been unable to reproduce the issue so far (using the publicly available code that's been provided. We'd also like to know the following, but can cover this in a call if you would prefer:
** Please do not share any email addresses of the customers publicly on this GitHub issue
mpinter
commented
7 months ago @cwomack would be happy to jump on a call (and thank's a lot for being involved in this). We can likely arrange with both of us with @MarekBodingerBA , probably Tuesday the earliest as Monday is still easter holiday, or later in the week if preferred.
So far:
@ and . in email and a single "á" character in given_name attribute (but we have those in a lot of users). I've looked for any hidden whitespace or weirdness in the attributes, none found. After last attempt I've also tried temporarily changing the email on another account to the same one copied from the accounts attributes, just adding an extra character at the end, and could not reproduce the issue. But as for the commonalities, we still need to try fishing out other users - we don't have the ids of the users affected from the logs, the one we have we have been able to link to a support ticket with screenshot with the time of the error happening.mpinter
commented
7 months ago Updated info - we've tried changing the pw and logging into the 2bf74b91-22f2-46c4-b342-74ede104a7e4 user account and could not reproduce the issue. Waiting on confirmation from the user whether the issue keeps happening on their side.
We've added the user agent info to our production logs, if we catch a new instance of the issue we'll be able to provide those.
cwomack
commented
7 months ago @mpinter, thanks for the update. Let us know if you're able to catch the new instance of this.
As for a call to review/connect, could you reach out to me on our Discord server and send me a DM with your email? Want to keep it off the public issue here. Have the same alias/handle there as here on Github, @cwomack.
MarekBodingerBA
commented
7 months ago @cwomack We were able to contact some of the users that it's happening to and with high certainty we can tell that it is device specific issue (however the user agents don't differ from successfully sign-ins), the same people were able to sign-in on a different device.
Also, it seems that these are not new users, so we think some residual cookies / local storage values can interfere with login, so we are now testing this approach: https://github.com/bratislava/konto.bratislava.sk/pull/924/files
We will inform you if it worked.
erinleigh90
commented
7 months ago @MarekBodingerBA Have you been able to validate this approach or are you still seeing this issue?
MarekBodingerBA
commented
7 months ago @erinleigh90 (Un)fortunately we haven't had any occurrences of the error since 5th March (with couple of thousands successful sign-ins). We deployed this on 8th March, so we cannot evaluate.
MarekBodingerBA
commented
6 months ago We haven't had the exception since then, I am closing the issue.
yp717
commented
6 months ago We are experiencing the same issue. I believe it may be related to the mismatch in the cookie store between Amplify v5 and v6. Our working hypothesis is that for users that were signed in during the upgrade to v6, there may be a mismatch in amplify's expectations that does not refresh the state correctly. After clearing the cookies manually, we are able to sign in with a user account that was affected by the switch.
armenr
commented
6 months ago We're getting bitten by this exact behavior currently...we're totally stuck. Unclear what a fix may be.
MarekBodingerBA
commented
6 months ago I am reopening the issue, we've had an occurrence on May 10th, we also have a log where user cookies has been removed, but the user didn't try to sign in again unfortunately, so we cannot really say if it helped or not.
cwomack
commented
6 months ago @yp717, @armenr, @MarekBodingerBA, @mpinter
We'll look into this further and try to reproduce. Do any of you have a minimal sample repo where this is easily reproduced in a Next.js app? We've tried to reproduce with the repo/samples originally provided in this issue, but didn't have any luck on our side.
mwernsen
commented
6 months ago I've just ran into the UnexpectedSignInInterruptionException myself as well, with the additional message: "Unable to get user session following successful sign-in". They are only showing up in the webkit browser, so as @MarekBodingerBA wrote, it might be device specific.
I ran into these issue while settings op playwright testing for my NextJs application. The very basic sign-in test succeeds on chromium and firefox browser, but fails for the webkit browser. I'm running the most recent version of amplify: 6.3.2.
ColtonGlasgow13
commented
5 months ago I'm having an identical issue to @mwernsen, where the sign-in fails on webkit with "Unable to get user session following successful sign-in" but is fine otherwise. This is happening in playwright, but it also happens if I open up a safari browser and try to log in manually. Has anyone found a solution to this?
HuiSF
commented
5 months ago Thanks for the report @mwernsen @ColtonGlasgow13 regarding the Webkit based browsers, we will investigate.
HuiSF
commented
5 months ago Hi @mwernsen @ColtonGlasgow13 When you were seeing the issue with a Webkit based browser, were you testing with a local development server? Also what protocol was the server on? http or https?
ColtonGlasgow13
commented
5 months ago Thanks for looking into it so soon @HuiSF, I'm on a local dev server using http with next.js. The issue is happening whether I use next dev or next start, but I haven't noticed it happening on production builds deployed to Amplify.
HuiSF
commented
5 months ago Thanks for the quick response @ColtonGlasgow13 !
When passing { ssr: true } to Amplify.configure(), Amplify initiates a cookie store interface and stores the auth tokens in the browser cookie store. By default, following the best practices, it sets the cookie secure attribute to true. Webkit-based browsers, such as Safari, restrictively require the server to run with the https protocol; otherwise, they ignore any cookie operations. Due to this, after a user signed in, the auth tokens were not written into the cookie store, hence the failure.
HuiSF
commented
5 months ago Hi @armenr @MarekBodingerBA could you get the info what browser did the end users use to trigger this issue?
ColtonGlasgow13
commented
5 months ago Thanks @HuiSF, that solved it. Not too hard of a fix with the --experimental-https flag.
cwomack
commented
5 months ago Just wanted to add another possible scenario where this UnexpectedSignInInterruptionException may occur. If the client browser has denied all cookies, then it's possible that the error can be thrown due to Amplify needing access to the cookie store interface.
cwomack
commented
5 months ago @MarekBodingerBA and @armenr, want to ping you both again to see if you had a chance to review @HuiSF's comment. Let us know if you're still experiencing this issue.
cwomack
commented
3 months ago Closing this issue as we have not heard back from you. If you are still experiencing this, please feel free to reply back and provide any information previously requested and we'd be happy to re-open the issue.
Thank you!
armenr
commented
3 weeks ago Sorry for being late to this @HuiSF & @cwomack -- It turned out to be a terrible configuration issue, whereby the app was being run in non-SSR mode (locally), but there was a config elsewhere still telling the rest of the app that it is, in fact, running in SSR.
Stated simply: PEBKAC
Before opening, please confirm:
JavaScript Framework
React, Next.js
Amplify APIs
Authentication
Amplify Version
v6
Amplify Categories
auth
Backend
Other
Environment information
Describe the bug
After update to Amplify V6, part of our userbase started reporting being not able to sign in. In the logs we've found that our users are getting
UnexpectedSignInInterruptionException(150 instances in two weeks since the update, with thousands of active users). https://github.com/aws-amplify/amplify-js/blob/0ddaa3cc1257f5f006e5c3d534e19e866521c4bd/packages/auth/src/providers/cognito/utils/dispatchSignedInHubEvent.ts#L30It was not possible to Google any instance of anyone getting the same error, also there are no issues mentioning this either. The provided remedy in the
recoverySuggestionis to "ensure cookies can be correctly set from your server". I suspect that if our server wouldn't be able to set cookies correctly, it would happen in 100% cases, therefore I think it is a bug.After trying on 10s of users, we were not able to reproduce the issue ourselves, however our project is completely open source which makes it easy to share the code:
Amplify config: https://github.com/bratislava/konto.bratislava.sk/blob/ba71f78deed6202541dec776efeddc239be3766e/next/frontend/utils/amplifyConfig.ts Login sequence: https://github.com/bratislava/konto.bratislava.sk/blob/ba71f78deed6202541dec776efeddc239be3766e/next/pages/prihlasenie.tsx#L36 Environmental variables: https://github.com/bratislava/konto.bratislava.sk/blob/ba71f78deed6202541dec776efeddc239be3766e/next/.env.bratiska-cli-build.prod package.json: https://github.com/bratislava/konto.bratislava.sk/blob/ba71f78deed6202541dec776efeddc239be3766e/next/package.json Amplify config before the update: https://github.com/bratislava/konto.bratislava.sk/blob/f9e2ec6c0f57b0fb8ff871b0d3490d58f6ac6acf/next/frontend/utils/amplify.ts Login sequence before the update: https://github.com/bratislava/konto.bratislava.sk/blob/f9e2ec6c0f57b0fb8ff871b0d3490d58f6ac6acf/next/pages/prihlasenie.tsx#L43
Thank you.
Expected behavior
The authentication process should successfully complete without any errors, allowing users access to their accounts without any interruptions or discrepancies in the sign-in flow.
Reproduction steps
As the issue has not been reproducible on our end despite attempts with tens of users, we're unable to provide specific steps that consistently trigger the
UnexpectedSignInInterruptionException. Below are the general steps a user would follow, which for some results in the error:Code Snippet
Log output
aws-exports.js
No response
Manual configuration
No response
Additional configuration
No response
Mobile Device
No response
Mobile Operating System
No response
Mobile Browser
No response
Mobile Browser Version
No response
Additional information and screenshots
No response