feat: experimental testing for split session and user storage#32833
Closed
hf wants to merge 1 commit into
Closed
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
2 Skipped Deployments
|
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
RVP97
approved these changes
Feb 10, 2025
hf
added a commit
to supabase/auth-js
that referenced
this pull request
Jun 4, 2025
A common complaint when using Supabase in SSR is that the cookie size is
huge. Some server configurations are not able to use such large cookies.
A major contributor to cookie size is that the user object is stored
alongside the access and refresh tokens. This object _should not be used
on the server_ but nevertheless has to exist to make this library happy.
This change introduces the ability for this library to store the user
object in a separate storage location. For now it's experimental mode to
be proofed before being widely adopted.
**How does it work?**
You can initialize the client by passing in a new option `userStorage`
in addition to the already existing and optional `storage` option. By
default `userStorage` is not set and a single storage is used for all
elements of the session (including `user` property).
If `userStorage` is set, **all future changes to the session** will
write the user there, and the rest of the session object to `storage`.
**Unsolvable Problems**
Say you set up the client like so:
```typescript
new GoTrueClient(URL, {
// ...
storage: cookieStorage,
userStorage: window.localStorage,
})
```
On the server, the cookies -- obviously -- will not contain the `user`
object. Because the `Session` type defines `user: User` as non-nullable,
attempting to access a property on this object will throw an exception.
Instead you should always call `getUser()` to fetch a trusted and fresh
user object. This problem will be solved in v3 of this library.
**Testing**
[This PR](supabase/supabase#32833) can be used
to test this PR before merging. Merging should be safe as this is opt-in
behavior for now.
---------
Co-authored-by: Cemal Kilic <cemalkilic96@gmail.com>
Co-authored-by: Cemal Kılıç <cemalkilic@users.noreply.github.com>
mandarini
pushed a commit
to supabase/supabase-js
that referenced
this pull request
Oct 2, 2025
A common complaint when using Supabase in SSR is that the cookie size is
huge. Some server configurations are not able to use such large cookies.
A major contributor to cookie size is that the user object is stored
alongside the access and refresh tokens. This object _should not be used
on the server_ but nevertheless has to exist to make this library happy.
This change introduces the ability for this library to store the user
object in a separate storage location. For now it's experimental mode to
be proofed before being widely adopted.
**How does it work?**
You can initialize the client by passing in a new option `userStorage`
in addition to the already existing and optional `storage` option. By
default `userStorage` is not set and a single storage is used for all
elements of the session (including `user` property).
If `userStorage` is set, **all future changes to the session** will
write the user there, and the rest of the session object to `storage`.
**Unsolvable Problems**
Say you set up the client like so:
```typescript
new GoTrueClient(URL, {
// ...
storage: cookieStorage,
userStorage: window.localStorage,
})
```
On the server, the cookies -- obviously -- will not contain the `user`
object. Because the `Session` type defines `user: User` as non-nullable,
attempting to access a property on this object will throw an exception.
Instead you should always call `getUser()` to fetch a trusted and fresh
user object. This problem will be solved in v3 of this library.
**Testing**
[This PR](supabase/supabase#32833) can be used
to test this PR before merging. Merging should be safe as this is opt-in
behavior for now.
---------
Co-authored-by: Cemal Kilic <cemalkilic96@gmail.com>
Co-authored-by: Cemal Kılıç <cemalkilic@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Allows testing split session and user storage.
Steps to test: