Closed alexvcasillas closed 1 year ago
I can't reproduce the malformed credential. I'm using OAuth instead of email/pass; but I'd assume a JWT is created with the same code, no matter which is used.
As for setSession()
, we're now required to pass in a "session". But not a whole session, just the access_token
and refresh_token
. The docs have not been fully updated to reflect this, but the Parameters section is correct.
const { data, error } = await client.auth.setSession({ access_token: 'value', refresh_token: 'value' })
After following this example from the auth-helpers
repository I managed to have all these features fully working and working like I charm I have to say.
Having upgraded to Next 13 seemed to be the root cause of this issue as now I can see that the supabase-auth-token
is looking the same way as the one that I pointed out to be "malformed" because it didn't look like in the previous version.
I think it's safe to close this bug report as it relates to using supabase-js
the same way as we did for next<13
, which now is different and I've figured it out thanks to the given example. Hope others can find this example helpful too :)
I am having the same issue. But I am not in NextJS-land.
I am working on a server-side Solid Start solution, using cookies. Having said that the reproducing sample is just about identical.
The only difference is that I am getting the access_token and refresh_token from a cookie.
The weird thing is that the setSession
call completes fine (I am passing an object with the access and header tokens). It even returns the session-data and the error property is indeed null.
The error comes from the getUser()
call. And it is exactly the same as described in this issue.
A few days ago when I started working on the code, it was working too (AFAICT). I first then started to see this a few times and now it is there every time.
Is it necessary to even call getUser? The samples all show the setSession call without using the returned data, which includes the user. Can't I just use the user returned?
In this app I am not exposing the supabase-client at all in the browser. All the code is run server-side. I am creating a secure cookie that contains the access and refresh tokens (encrypted). So, every request from the client to the server will pass that cookie and I will then be able to authenticate the user (via setSession
).
Should I then update the refresh-token in my cookie after the call, if it has changed? As I believe that it may have been rotated - and I guess it should not be reused.
Although, I haven't tried to actually do anything after the setSession
call yet. That might fail just as badly as the getUser
call of course... I have just been passing the user-data back to tell the browser-client that the user is logged in. Got to go now, but I guess that is something that I will need to test...
Not sure if this is a perfect solution, but I made some option-changes to the call to createClient
, which seems to have fixed the issue for me.
const supabase = createClient(supabaseUrl, supabaseKey, {
auth: {
autoRefreshToken: false, // All my Supabase access is from server, so no need to refresh the token
detectSessionInUrl: false, // We are not using OAuth, so we don't need this. Also, we are manually "detecting" the session in the server-side code
persistSession: false, // All our access is from server, so no need to persist the session to browser's local storage
},
It seems that after I added persistSession: false
the getUser
call no longer resulted in an error.
Not sure if this is a perfect solution, but I made some option-changes to the call to
createClient
, which seems to have fixed the issue for me.const supabase = createClient(supabaseUrl, supabaseKey, { auth: { autoRefreshToken: false, // All my Supabase access is from server, so no need to refresh the token detectSessionInUrl: false, // We are not using OAuth, so we don't need this. Also, we are manually "detecting" the session in the server-side code persistSession: false, // All our access is from server, so no need to persist the session to browser's local storage },
It seems that after I added
persistSession: false
thegetUser
call no longer resulted in an error.
Yeah, there's no good docs on this. For getUser()
to work server-side, persistSession
needs to be false
.
@Spiralis @j4w8n thanks for bringing this up folks, I'm passing this as a feedback to the Auth team :)
No problem @soedirgo. What I said is only true if you don't pass an access token into getUser. Because in that case, it calls getSession; which is where things really breakdown.
Gary opened an issue about it https://github.com/supabase/gotrue-js/issues/539
There are also issues with using setSession on the server side without setting persistSession to false. Not because of that method's direct code, but because it calls _saveSession
and it's code causes issues.
I have also added passing the access_code
(since I have it from setSession
), as I understand that this reduces the work that getUser
need to do.
Yep, that's a good way to do it on the server side.
I was getting this error because I have an Express backend and want to attach the user object in Express middleware. I am passing the accessToken / refreshToken via the serverSideRendering docs.
In the middlware, I was calling
const supabase = createClient<Database>(
SUPABASE_URL ?? "",
SUPABASE_ANON_KEY ?? "",
);
supabase.auth.setSession(/*tokens*/)
// ...
supabse.auth.getUser() // returned the invalid claim error
Adding this flag (as referenced above) seems to have fixed it:
// Without this flag, we get "invalid subclaim" error on supabase.auth.getUser
const supabase = createClient<Database>(
SUPABASE_URL ?? "",
SUPABASE_ANON_KEY ?? "",
{
auth: {
persistSession: false,
},
}
);
I am experiecing this issue too.
I have an nx.dev monorepo with an SPA in React sporting Vite and an express app for backend stuff (both will go inside Tauri app).
Before I landed on the invalid claim: missing sub claim
problem I have been debugging a different issue also related to how I was using Supabase. I was getting util.inherits is not a function
, because I was trying to use one client for both express and react app (it is a monorepo, why duplicate configs). Anyway, one guy was having an issue with the util.inherits
and the underlaying problem was that he was using jsonwebtoken
that doesn't want to work with Vite because some nodejs APIs are not polyfilled. I split my code into two separate clients, which solved the util.inherits is not a function
bug, but it gave me the invalid claim: missing sub claim
one.
Could it be that the underlying issue is in Supabasejs not communicating properly with server-based build frameworks? This library is using jsonwebtoken
. The "bug progression" on my end could indicate that jsonwebtoken
is missing context, since it is not polyfilled anywhere. This problem also exists for browser's storage APIs and I bet jsonwebtoken
is used here to en/decode data.
Since Supabasejs is isomorphic the solution could be in polyfilling jsonwebtoken
's missing node APIs or replacing jwt
with eg. jose that seems to be supported across environemnts.
I have no idea if any of this applies to invalid claim: missing sub claim
, but I am going to debug it some more to narrow down the problem.
I ran into this issue tonight, getting invalid claim: missing sub claim
, and ended up on this issue so I'll add my solution here for intrepid explorers 😄
I'm doing something similar to what was mentioned above with a client that logs in via Supabase, then sends the access/refresh tokens to a separate server.
The problem for me was that client.auth.setSession
returns a Promise
! I was just missing an await
...
const supabaseUserClient = createClient(supabaseUrl, supabasePublicKey, {
auth: {
autoRefreshToken: false,
persistSession: false,
},
});
// you have to `await` this promise for the session to actually be set!
await supabaseUserClient.auth.setSession({
access_token: accessToken,
refresh_token: refreshToken,
});
return supabaseUserClient;
I'm having that issue using supabase with expo.
When I set persistSession: false
authentication works but I definitely want to persist my session.
Any idea if there is another way to fix?
I'm having that issue using supabase with expo. When I set
persistSession: false
authentication works but I definitely want to persist my session. Any idea if there is another way to fix?
I'd recommend opening your own issue. This one is pretty stale. You can also ask on the Discord server.
I also encounter this problem, set persistSession to false not works for me, and also this answer link is dead, so this problem is not resolved for me. Is this isssue answered somewhere or is it not fix yet?
I also encounter this problem, set persistSession to false not works for me, and also this answer link is dead, so this problem is not resolved for me. Is this isssue answered somewhere or is it not fix yet?
I'm not 100% sure I understand your problem but have you tried the solution from my comment in another issue:
https://github.com/supabase/supabase-js/issues/786#issuecomment-1792692206
Too bad to see that this error still exists. Especially when making a POST request inside a Next js /app dir.
How do we get around this? 🤔
Any workarounds? Using supabase on both server and client log-outs users from time to time, really annoying :( @awalias can we please reopen this issue since the error still occurs?
Same issue here on Safari, working fine on Chrome.
Bug report
Describe the bug
Credentials are malformed are not being stored properly and therefore the client is not able to lately resolve the session
After calling
supabase.auth.signInWithPassword({email, password})
this strangely formatted token is generatedAnd later on, doing
await supabase.auth.setSession(token);
throws the following error:This is the versions that I'm currently using:
This worked before with versions:
And I have my product live without issues https://otpfy.com, but after upgrading everything to latest, it stopped working as expected 🤔
To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:
I'm using
next
for everything relatedSign in a user server-side
Try to see if the user is authenticated after server-side:
Expected behavior
I should be able to sign up a user and work fine as expected
System information