-
-
Notifications
You must be signed in to change notification settings - Fork 186
feat: introduce experimental split user and session storage #1023
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
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
b9b1d39
to
6d757c8
Compare
6d757c8
to
a924a9d
Compare
cemalkilic
reviewed
Jun 3, 2025
hf
commented
Jun 3, 2025
cemalkilic
approved these changes
Jun 3, 2025
34fcef0
to
33848e3
Compare
hf
added a commit
that referenced
this pull request
Jun 6, 2025
Due to bad typing the `null` case of a missing session when using the `userStorage` option introduced in #1023 caused a crash.
hf
pushed a commit
that referenced
this pull request
Jul 14, 2025
🤖 I have created a release *beep* *boop* --- ## [2.71.0](v2.70.0...v2.71.0) (2025-07-10) ### Features * fallback to `getUser()` if the `kid` of the JWT is not found ([#1080](#1080)) ([9721f60](9721f60)) * introduce experimental split user and session storage ([#1023](#1023)) ([e7b2f21](e7b2f21)) * make `getClaims()` non experimental, add global cache ([#1078](#1078)) ([ffe13d7](ffe13d7)) * remove solana dependency by inlining types ([#1079](#1079)) ([7665f94](7665f94)) ### Bug Fixes * handle null current session with split session storage ([#1071](#1071)) ([bc6192a](bc6192a)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
hf
pushed a commit
that referenced
this pull request
Jul 17, 2025
Not all JS runtimes support `structuredClone` (introduced in #1023). (Example: supabase/supabase-js#1504) - As the session data is safe to JSON serialize, replace `structuredClone` use with JSON de/serialize. - Added the helper function to increase the readability (making the intent clear).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
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 optionalstorage
option. By defaultuserStorage
is not set and a single storage is used for all elements of the session (includinguser
property).If
userStorage
is set, all future changes to the session will write the user there, and the rest of the session object tostorage
.Unsolvable Problems
Say you set up the client like so:
On the server, the cookies -- obviously -- will not contain the
user
object. Because theSession
type definesuser: User
as non-nullable, attempting to access a property on this object will throw an exception. Instead you should always callgetUser()
to fetch a trusted and fresh user object. This problem will be solved in v3 of this library.Testing
This PR can be used to test this PR before merging. Merging should be safe as this is opt-in behavior for now.