https://supabase.com/ logo
Hi, I've been playing around with the supabase-cus...
# help
d
Hi, I've been playing around with the supabase-custom-claims repo and I've run into a bit of a problem with request.jwt.claims
n
Hello @derpwingduk! 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.
d
I'm not sure what is causing this, but on a Supabase project that I've been working with for months, when I try to run the
get_my_claims()
function from supabase-custom-claims, I get an empty object.
Upon further digging, it seems that for some reason in my DB,
request.jwt.claims
is not recognized. Perhaps something I messed with in my early days of toying with this project caused this to happen? Not sure how to correct it.
I spun up a new Supabase project and connected the supabase-custom-claims, and wrote a little function to get the contents of
request.jwt.claims
, and everything works as expected.
g
Is this a SB instance or local. The claims code changed a bit when PostgREST 9 came out. I don’t have the date handy, but it was several months to 6 ago. The system should deal with both, but there is a flag for backward compatibility. https://postgrest.org/en/stable/api.html#http-context
d
Aha ok; it's a hosted SB instance
I believe I started this project in August of last year so perhaps that is the issue. I'll read the docs you posted.
OK cool, I am able to access the required data with
request.jwt.claim.app_metadata
since my instance is using postgres 13.3. Thanks for the help!
g
Can you throw an issue on that repository pointing that out for others.
d
Sure thing 👍
n
Thread was archived by @derpwingduk. Anyone can send a message to unarchive it.
j
@edelacruz Maybe this is something relevant to your issue?
e
@jaitaiwan I solved my problem by creating a new project. I probably messed up something in my first project that is preventing auth.uid() to work properly. I just created a brand new project, created some users/logins and now it works like a charm. Here is my working function in case you are interested.
Copy code
-- drop function get_all_users;
create or replace function get_all_users() 
  returns table (
    user_email varchar,
    user_name text,
    user_role text
  )
  language plpgsql
  security definer set search_path = auth
  as $$ 
  declare user_role text;
  begin
    select raw_user_meta_data->>'role' 
      from auth.users
      into user_role
      where id = auth.uid();
    if user_role <> 'admin' then
      raise notice 'User Role: %', user_role;
      return;
    else
      return query
        select
          u.email,
          u.raw_user_meta_data->>'name' as name,
          u.raw_user_meta_data->>'role' as role
          from auth.users u;
    end if;
end $$;
j
Great job
e
@jaitaiwan Thanks. Except I need to use app_metadata instead of user_metadata. Also I probably do not need to do the search in the database. The role is in the JWT. Here is a nice article: https://dev.to/supabase/supabase-custom-claims-34l2