supabase / auth

A JWT based API for managing users and issuing JWT tokens

Home Page:https://supabase.com/docs/guides/auth

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Too long strings in user_metadata causing authentication to break

kluplau opened this issue · comments

Bug report

  • I confirm this is a bug with Supabase, not with my own application.
  • I confirm I have searched the Docs, GitHub Discussions, and Discord.

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 the cookieOptions set to access_token.

// This works fine
await supabase.auth.admin.updateUserById("user-id-here", {
  user_metadata: {
    images: "short string",
  },
})

// This breaks authentication
await supabase.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:

  1. The update appears to succeed but actually breaks the user's authentication.
  2. Multiple cookies are set with incorrect names (e.g., "access_token.0", "access_token.1").
  3. 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.
  1. 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

  1. Use the supabase.auth.admin.updateUserById method to update a user's metadata.
  2. Set a value in the user_metadata object with a shorter string.
  3. Observe that the update succeeds.
  4. Now, try to update the same field with a longer string. I haven't found the exact length.
  5. Observe that this causes the authentication to break without a clear error message.
  6. 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.

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?