Open kluplau opened 1 month ago
Issues 2 and 3 are expected.
With 2, the ssr package now stores the cookie differently and prefixes it with "base64_".
3 happens via their cookie chunking method, if it's determined that the resulting cookie would be too large for browsers to store. The library handles putting this all back together, but if you access the cookie yourself, that would require more work on your part.
I wasn't able to find any documentation on this. Do we have that?
I wasn't able to find any documentation on this. Do we have that?
I don't believe the docs mention it, but I could be wrong.
Are you looking for docs about how the cookie is stored or about how to handle it when grabbing the cookie yourself?
Bug report
Describe the bug
We've encountered an unexpected behavior when updating user_metadata using the supabase.auth.admin.updateUserById method. It appears that there's an undocumented length limitation on the values stored in user_metadata. When this limit is exceeded, it causes authentication to break in an unclear manner and results in multiple, malformed cookies being set.
It's not per key-value pair, it's the accumulated length of the meta_data. A bunch of short key-value pairs results in the same behavior.
We are using the SSR package with the
name
in thecookieOptions
set toaccess_token
.When the value exceeds a certain undocumented length, the following issues occur:
To Reproduce
Expected behavior
A clear and concise description of what you expected to happen.
Additional context
This issue seems to be related to the discussion in #9972, where similar unexpected behavior with user_metadata was reported. However, our case specifically highlights a potential length limitation and cookie malformation that wasn't mentioned in that discussion.