supabase / ssr

Supabase clients for use in server-side rendering frameworks.
MIT License
58 stars 6 forks source link

using custom_access_token_hook works in 0.3.0 but not in any newer packages #66

Open oldbettie opened 1 week ago

oldbettie commented 1 week ago

Bug report

Describe the bug

When upgrading from v0.3.0 to any newer version of the ssr package it causes out custom jwt claims function to not work correctly.

I can confirm, the only thing that was changed was this package. We followed this to modify out JWT's https://supabase.com/docs/guides/auth/auth-hooks/custom-access-token-hook?queryGroups=language&language=sql

It works fine with v0.3.0 but when we use a later package the session cookie that is saved looks something like this _base64encoded<what_looks_like_the_jwt_access_key> its not even an object its just literaly that as a string.

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

  1. Createa project and activate the custom JWT hook and implementation
  2. Create an account and try to login with SSR package v0.3.0
  3. Change to package > 0.3.0 and repear
  4. See cookie saved is not a real cookie

Expected behavior

Should save the session cookie correctly

Screenshots

System information

j4w8n commented 1 week ago

So are you having an issue with the hook itself, or when trying to parse the session cookie?

oldbettie commented 1 week ago

I think the biggest issue is not that its an issue with the package but instead an issue with how you guys relay information about switching from v0.3 to v0.5. After loads of research I figured out that you have changed the cookie completely. We have many micro services including ones that are not integrated with supabase at all that just require the access_token and refresh_token from the cookie upgrading our core packages that mints JWT's to version 0..5 will require me to change every microservice we have to use the new cookie with the decoder. This should really be documented in detail somewhere.

I really wish the rewrite had a big more thought put into it. There are issues with the cookie size exceeding a single cookie. Why wouldnt you store just the access_token & refresh_token in a single cookie and any other defined content in another cookie. This would greatly reduce the change of chunking the actually used auth cookie since over half the content is stuff we don't care about