Open oldbettie opened 1 week ago
So are you having an issue with the hook itself, or when trying to parse the session cookie?
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
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:
v0.3.0
Expected behavior
Should save the session cookie correctly
Screenshots
System information