Self-hosted Supabase combined with supabase/ssr sets 4 cookies in some occasions

[yekta]

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 are using self-hosted Supabase and supabase/ssr package. We have a SvelteKit app and we followed the docs. Usually things work. For a reason I'm still not able to understand, sometimes when logging with Google OAuth, supabase/ssr package seems to be setting 4 cookies as opposed to the usual 2-3 cookies. This somehow breaks the entire thing, the request doesn't even reach our SvelteKit app afterwards, I'm not sure if it's because of the header size or something internal thing is going on. We've raised the buffer size for nginx in our Kubernetes cluster significantly but that didn't help either.

Logging out removes the cookies regardless of the count (2 or 3). 4 cookie version, I tried removing the cookies manually, that fixes the error. Next time I log in with that specific user, there are 4 cookies again and everything breaks.

Update: We have removed Cloudflare from in front of our app and things seem to work. However, the cookie string is about 10,500 characters long which seems significantly more than usual. This is a pretty big issue since Cloudflare has a huge market share and its header size limits aren't unreasonable compared to other similar services. That long of a cookie also breaks Nginx default config which also seems weird considering its one of the most popular reverse proxies around. I'm not sure if 4 cookies are actually needed, but if they are maybe there is a better solution without breaking such popular pieces of internet infra.

To Reproduce

Even though we tried multiple things already, at this point we don't have a consistent way to reproduce it. What I do know is, for a specific user there is consistently 4 cookies.

Expected behavior

We would expect 2 cookies at all times, and for supabase/ssr to not break our SvelteKit app.

System information

• OS: macOS
• Browser (if applies): Chrome 128.0.6613.85
• Version of supabase-js: 2.45.1
• Version of supabase ssr: 0.5.1
• Version of Node.js: 20.17.0

[j4w8n]

The ssr library will create multiple cookies if the size is going to be larger than the browser's allowed limit. This is expected and necessary behavior.

Can you share the size of each of the four cookies? That way, we know if ssr is only creating the minimum amount needed.

[yekta]

That's good to know but simply splitting them isn't enough. Since even though that way it's under the per cookie limit, it's still over the total header size limit:

Is 11,000 characters really needed to make this work? Every auth library I used, or seen getting used besides this one has perfectly fine auth with cookies under 6000 in total. Most of them are under 3000. If these were incompatible with some unknown technologies I would understand but we are talking about Cloudflare and Nginx defaults. I actually can't put the site behind Cloudflare no matter what with cookies those size.

[j4w8n]

I can't speak to the subtleties of header size limits; but ssr cookie sizes are usually reasonable. It's when you start getting into the OAuth world that the cookie can sometimes need broken into multiple.

Having a cookie that large seems like there is a lot of data being added to it: perhaps by the OAuth provider or maybe via Supabase *_meta_data fields??

[yekta]

It's Google OAuth so whatever they are adding we are not editing. We ask for minimum level of permissions on Google OAuth too so this is as small as it gets. We didn't add anything to the meta_data ourselves. We aren't doing anything besides the defaults.

This isn't an issue with some random 3rd party doing something weird. This is Google, Cloudflare and Nginx. So feels like things should work. Even if you change the Nginx defaults like us, Cloudflare will still be broken.

I don't know what Supabase does different compared to all the other platforms I used auth systems of but I've never seen an auth library breaking Cloudflare. It's not just Cloudflare either, the size is above the limits for similar services too.

[yekta]

Update: The account that leaves 4 cookie chunks behind has very similar length raw_user_meta_data compared to accounts that leave 2 cookie chunks behind. The user object itself is also the same length compared to other accounts that signed in with Google OAuth. So I'm having a hard time understanding why one account would need 2 chunks, the other would need 4. Even 2 chunks is dangerously close to standard header limits by the way which means if some other part of your app is setting some medium size cookies, things could get broken.

[hf]

Is 11,000 characters really needed to make this work? Every auth library I used, or seen getting used besides this one has perfectly fine auth with cookies under 6000 in total. Most of them are under 3000.

We are aware of the size issue and are working towards lowering that. This is going to be done primarily with the rollout of asymmetric JWTs currently slated for early October 2024.

Check the custom access token hook to really make a minimal JWT which should help a bit: https://supabase.com/docs/guides/auth/auth-hooks/custom-access-token-hook?queryGroups=language&language=http

[yekta]

I did this instead:

supabase/auth#1754