supabase / auth-js / 15436819162

71%

push

github

feat: introduce experimental split user and session storage (#1023)

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](https://github.com/supabase/supabase/pull/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>

692 of 1267 branches covered (54.62%)

Branch coverage included in aggregate %.

19 of 65 new or added lines in 2 files covered. (29.23%)

1155 of 1598 relevant lines covered (72.28%)

119.61 hits per line