-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Auth] - idToken cookie is too large to store, so server side authentication does not work #11649
Comments
In debug mode, I got this extra information:
|
Seems to be a size issue! I tried to manually copy my idToken into the cookies, and the idToken length was around 6k characters, which is definitely more than what can be stored in cookies (4096). Any workaround for this? Maybe for server side, we can split the token across multiple cookies
thoughts? @cwomack |
Hello @asp3, and thanks for opening this issue. As you've already indicated, there's usually a cookie size limitation of 4 KB (4096 bytes) that browsers implement. If you're at over 6k bytes, it's likely that you'd experience this on most (if not all) browsers I think. Can you help me understand the reason why the cookies are so large? Do you have a large number of attributes within your User Pool that's causing this? |
Hey @cwomack, thanks for the response - I guess this isn't next 13 app dir specific, yeah. We use the If this is pretty specific to our use case, I could make a fork and just make the changes to the cookie storage/retreival myself (if you could provide some code pointers, that would be great), but it seems like others might be running into this as well, so maybe it would be useful to support larger payloads for server side. Please let me know your thoughts! This is blocking some of our larger refactors, so looking to either |
any update on this? @cwomack This is a blocking issue for us, so I was wondering if you could give a code pointer of where the code to store and retrieve cookies is so we could fix this issue |
@asp3, thank you for the additional context above! There’s not a straightforward solution to this at the moment, so we’ll convert this issue into a feature request to see if we can provide a better option out of the box when customers run into this limitation. Your use of The only two workarounds that I can think of here would be to either:
|
@cwomack I know what changes need to be made (inside UniversalStorage), but I am not sure about the process for forking and using the built fork in my repo. Could you please provide some documentation around this part? |
In case anyone finds this later, here's how I fixed it. // awsConfig:
// UniversalStorage (copied from amplify/core, with minor modifications)
|
@asp3, that's awesome to hear you got it working and we appreciate you taking the time to add the comment showing your workaround! |
Before opening, please confirm:
JavaScript Framework
Next.js
Amplify APIs
Authentication
Amplify Categories
auth
Environment information
aws-amplify -> 5.3.4
Describe the bug
error The user is not authenticated
Expected behavior
This function should return the current user, as the cookies are set properly. in our backend, we recently made a change to our claims override, where we added a few more values. The cookies here, however, are well under the 4096 limit.
Reproduction steps
set up aws amplify with next 13 app dir.
log in.
notice that client side values work as expected. However, on server side, it returns user not authenticated.
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
The text was updated successfully, but these errors were encountered: