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
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 the cookieOptions set to access_token.
// This works fineawaitsupabase.auth.admin.updateUserById("user-id-here",{user_metadata: {images: "short string",},})// This breaks authenticationawaitsupabase.auth.admin.updateUserById("user-id-here",{user_metadata: {images: "long string long string long string long string long string long string long string long string long string long string long string long string long string long string long string long string long string long string long string long string long string long string long string long string long string long string long string long string",},})
When the value exceeds a certain undocumented length, the following issues occur:
The update appears to succeed but actually breaks the user's authentication.
Multiple cookies are set with incorrect names (e.g., "access_token.0", "access_token.1").
The content of these cookies is malformed:
The first cookie starts with "base64-" as expected, but is truncated.
The second cookie does not start with "base64-" and appears to be a fragment of a base64 encoded string.
These issues manifest as problems with the access token, causing the user to be unable to log in or use the application again.
To Reproduce
Use the supabase.auth.admin.updateUserById method to update a user's metadata.
Set a value in the user_metadata object with a shorter string.
Observe that the update succeeds.
Now, try to update the same field with a longer string. I haven't found the exact length.
Observe that this causes the authentication to break without a clear error message.
Check the cookies set by the application and observe multiple, incorrectly named and malformed cookies.
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: