You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a Next.js application using Amplify JS with guest identities enabled, there's an inconsistency in identity source between server and client components. The server-side correctly uses cookies for guest identity, but the client-side incorrectly uses localStorage instead of cookies, resulting in different identity IDs being used for the same guest user.
The bug only manifests for guest/unauthenticated users in Next.js applications, while authenticated sessions work correctly. This creates potential issues for applications relying on consistent identity management across server and client components.
Expected behavior
Both server-side and client-side sessions should use cookies as the source for guest identities, maintaining consistency across Next.js server and client components, just as they do for authenticated users.
Server-side session shows an identityId from cookies
Client-side session shows a different identityId from localStorage
The cookies and localStorage sections clearly show this discrepancy
Note: The authentication flow cannot be tested with this reproduction as it doesn't contain sign in flow. To verify the authenticated behavior, you would need to use your own environment variables and provide respective cookies.
I want to ask an extra question - I noticed something with the App Router (I've only used Pages Router in production before). Without middleware, on each page refresh a new guest identity gets created. But when I add this no-op middleware, the identity cookie gets set properly and stays consistent. As I understand, it is not possible to modify headers (therefore set the cookies) directly in pages. Is this the recommended way to handle identity cookies in Next.js App Router with Amplify?
Hello, @MarekBodingerBA 👋 and thank you for opening this issue. We're marking this as a bug, as it indeed appears that the identityId differs on the client side and server side for unauth role users. If we have any further questions or updates on progress for this, we'll follow up with a new comment.
Hi @MarekBodingerBA Could you also provide some more details about your use cases so we can do some analysis on this issue. Much appreciated.
Could provide sample code of how you are using the unauthenticated role from your server side?
Regarding the extra issue - "without the middleware, on each page refresh a new guest identity gets created", could you provide sample code for triggering this behavior?
Also regarding your extra question, Next.js App router doesn't allow SetCookie headers to be set from a React Server Component backed page route, but only from the middleware, an API route or a Server Action. So yes, in general, if you want to set consistent cookie, the middleware is the best spot.
Before opening, please confirm:
JavaScript Framework
Next.js
Amplify APIs
Authentication
Amplify Version
v6
Amplify Categories
No response
Backend
None
Environment information
Describe the bug
In a Next.js application using Amplify JS with guest identities enabled, there's an inconsistency in identity source between server and client components. The server-side correctly uses cookies for guest identity, but the client-side incorrectly uses localStorage instead of cookies, resulting in different identity IDs being used for the same guest user.
The bug only manifests for guest/unauthenticated users in Next.js applications, while authenticated sessions work correctly. This creates potential issues for applications relying on consistent identity management across server and client components.
Expected behavior
Both server-side and client-side sessions should use cookies as the source for guest identities, maintaining consistency across Next.js server and client components, just as they do for authenticated users.
Reproduction steps
Note: The authentication flow cannot be tested with this reproduction as it doesn't contain sign in flow. To verify the authenticated behavior, you would need to use your own environment variables and provide respective cookies.
Code Snippet
No response
Log output
No response
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
Guest Identity Output:
Authenticated Identity Output:
The text was updated successfully, but these errors were encountered: