search

supabase / auth-helpers

A collection of framework specific Auth utilities for working with Supabase.
https://supabase.github.io/auth-helpers/
MIT License
902 stars 237 forks source link

Auth token cookie chunk exceeds the size limit when using SSR setup #707

Closed artykr closed 8 months ago

artykr commented 9 months ago

Bug report

Describe the bug

Context: I ran into this in a Remix app but other implementations may be affected potentially.

When a user signs up using an email and then logs in through an external provider, like GitHub, for instance, the app_metadata value now includes two providers: email and GitHub:

"app_metadata":{"provider":"github","providers":["email", "github"]}

supabase/ssr splits the auth-token cookie into two chunks in this case: xxx-auth-token.0 and xxx-auth-token.1. According to the example here: https://supabase.com/docs/guides/auth/server-side/creating-a-client?framework=remix, I'm calling serialize on a chunk that produces a slightly longer string. The first chunk becomes too big and gets skipped by the browser.

To Reproduce

  1. Clone a sample Remix app that implements the SSR approach outlined in the docs: https://github.com/artykr/ssr-cookie
  2. Set up an OAuth app in GitHub.
  3. Set up a project in Supabase and configure the GitHub provider.
  4. Configure the app to use the Supabase project.
  5. To deploy it using fly.io: make sure to update the app name in fly.toml, set the environment variables mentioned in the README as secrets for the fly app, and run fly deploy.
  6. Create a user in Supabase, so that an email provider is linked to the user.
  7. Use the link on the main app page to log in using GitHub.
  8. Observe that the login doesn't happen and the cookie chunk is lost. The tricky part is that, in my case, it was just a bit longer, so it also depends on the length of the email address and user name.

Expected behavior

The cookie chunks don't exceed the browser size limit, and the user gets logged in as expected.

System information

astonfuture commented 9 months ago

I've been experiencing issues with the chunking as well - slightly different to the issue here though.

Seems like a potential workaround could be to implement the new auth hooks they announced last week to remove a bunch of data from the jwt's to avoid them ever exceeding the chunking size:

https://supabase.com/blog/supabase-auth-identity-linking-hooks

dalkommatt commented 9 months ago

Also experiencing this issue in next.js with the ssr package.

kangmingtay commented 8 months ago

hi @artykr, @astonfuture, @dalkommatt, we've fixed this issue in #726 for the supabase/ssr package - please try again and let us know if it's still a problem for you

bombillazo commented 8 months ago

We are getting the split auth cookie as well, how can we join it in our FE to read the cookie value properly?

charislam commented 8 months ago

@bombillazo, just to clarify, the cookie is being set but it is being split into multiple cookies: like cookiename.1, cookiename.2, etc.?

That is the intended behavior (otherwise the cookie would be too long and fail to set entirely), and @supabase/ssr accounts for this under the hood.

Do you need to access the cookie in your own FE code?

bombillazo commented 8 months ago

Hey, yes that is exactly the case, we need to read it in our FE code, are there any helpers in the supabase lib that does this or anyway to reconstruct the token value from the cookies?

charislam commented 8 months ago

Gotcha. We don't expose any helper functions for that. The code is pretty short, so you could copy-paste into your own utility functions, though honestly it might be easier to do a getSession call, which can get you the access token.

(You say FE so I assume you're running this code in the browser, just a friendly reminder never to use getSession on the server. If you need the cookie there, you should always, always call getUser first to make sure the JWT gets validated.)

https://github.com/supabase/auth-helpers/blob/a68e78bc9cb863217db75ac561de93874a85aafa/packages/ssr/src/createServerClient.ts#L63-L69

https://github.com/supabase/auth-helpers/blob/a68e78bc9cb863217db75ac561de93874a85aafa/packages/ssr/src/utils/chunker.ts#L65-L91

bombillazo commented 8 months ago

Thanks! We need this at places in our code where a supabase client is not possible to be instantiated, or we want to directly confirm with the browser cookies.