Skip to content

Conversation

hf
Copy link
Collaborator

@hf hf commented Aug 29, 2025

Adds an experimental option encode on the cookies object when using createBrowserClient() and createServerClient().

If this is set to tokens-only then only the user's access token and refresh token will be encoded in the cookies, causing significant cookie size savings, often greater than 50%. It utilizes split session storage in auth-js, with some trade-offs such as the inability to access the user property on the supabase.auth.getSession() object in the server. This wasn't supposed to be done anyway, and getClaims() is a secure alternative for it.

@j4w8n
Copy link
Contributor

j4w8n commented Aug 30, 2025

Nice.

Have you considered setting the fallback for userStorage to null in each case? Then the encode option would be a great way for developers to just not store user anywhere unless we set userStorage explicitly ourselves. This has the great benefit of avoiding the warnings of supabase/supabase-js#1709, since Supabase source code also calls getSession() for various things that trigger the warning; more secure all around.

@hf hf force-pushed the hf/split-session branch 2 times, most recently from 0679e64 to 816f906 Compare September 16, 2025 14:38
@hf hf force-pushed the hf/split-session branch from 816f906 to 32a260d Compare September 16, 2025 15:45
@hf
Copy link
Collaborator Author

hf commented Sep 16, 2025

@j4w8n Null userStorage would break existing semantics in auth-js. I'd rather it gets controlled by a flag like this instead until we figure out how to do this in the next major version properly.

@hf hf merged commit cf38b22 into main Sep 16, 2025
4 checks passed
@hf hf deleted the hf/split-session branch September 16, 2025 17:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants