https://supabase.com/ logo
Join Discord
Powered by
Hey folks, I'm wondering if there's any more infor...
# help
j
Hey folks, I'm wondering if there's any more information on custom claims: https://github.com/supabase/supabase/discussions/1148 We're trying to setup multi-tenancy and slowly migrate an existing graphql w/ non-postgres db across fully into supabase and hoping to not have to do a completely custom implementation with raw_app_metadata. My biggest concern and the reason I ask, is there's no contract that I'm aware of that will allow me to update raw_app_metadata server-side and be ensured that it will persist when subsequent sign-in providers for a user's account for example are added. Knowing that go needs types and that gotrue might not be aware of the additional fields I add to the json structure, I'm concerned it might get overwritten.
n
Hello @jaitaiwan! This thread has been automatically created from your message in #843999948717555735 a few seconds ago. We have already mentioned the @User so that they can see your message and help you as soon as possible! Want to unsubscribe from this thread? Right-click the thread in Discord (or use the ``...`` menu) and select "Leave Thread" to unsubscribe from future updates. Want to change the title? Use the ``/title`` command! We have solved your problem? Click the button below to archive it.
🆕 MFA ETA for Supabase
b
n
MFA ETA for Supabase
j
Heck yes! Does gotrue support that though?
b
Does gotrue support what? The custom claims stuff? Yes, I wrote it to work with apps where I'm already using Supabase Auth (GoTrue) to authenticate.
j
Sorry @burggraf what I should have said was do those claims land in the token?
b
Yes they do
j
Gotcha! That’s good news
@burggraf Sorry to bug you... two questions: 1. Is there some documentation you can refer me to about how request.jwt comes about? 2. When you run those sql commands you referenced. Is it expected that you run them in the public schema?
b
1. Sorry I don’t but you can look at the source for GoTrue
2. Just run them in the query editor window.
You don’t really run sql inside if any particular schema
j
@burggraf This is a surprising thing to me in your custom claims... At what point would the db get an expired token?
Copy code
IF extract(epoch from now()) > coalesce((current_setting('request.jwt.claims', true)::jsonb)->>'exp', '0')::numeric THEN
        return false; -- jwt expired
      END IF;
b
This is just a special check to make sure you're not getting an expired token.
So let's say a user opens a browser and logs in. Then goes on vacation and comes back and refreshes the browser.
They'd still be sending the old token. This checks to makes sure the token is still valid, which in this case it's not. So the user would need to log into your app again to get a fresh token. It's just a security measure.
j
@burggraf I thought that gotrue would be verifying this first which is why I asked?
b
GoTrue verifies the user and issues the token, yes.
But once the token is sent to your application it's stored in localstorage, so it's possible that your app could attempt to send an expired token to the API. This is just double-checking that.
GoTrue may check it in the request, depending on what you're doing, and it may never get through to my function(s) -- I just always double-check the validity of the token for safety.
j
Should still note I’m hoping for a timeline on when mfa might land
b
You'll have to ask the auth team directly about this one (maybe on GitHub discussions?)
j
Ah ok
PreviousNext
Powered by