PricingBlog

What is Best Practice to have role based access of Components and Pages using Supabase?

  • the_guy01-1211771028011884594

    the_guy

    2 years ago

    As the title suggests, I plan to implement role based access on top of authenticated/non authenticated access.
    What is best practice here to ensure the user can not brute force his way into getting access by setting some flags through console as example?
    2
  • yoelfdz-1211773740342583297

    yoelfdz

    2 years ago

    Interested on this too 🙋🏻‍♂️
  • lucasg-1211774916366565496

    Lucas G

    2 years ago

    I'm using custom claims baked into the JWT to handle access. Maybe that approach could work for you guy's use cases
  • the_guy01-1211775471633829889

    the_guy

    2 years ago

    https://youtu.be/WUD1RLSd3U0?t=710

    I found this way on how to do it.
    It seems easy enough and similar to what I am doing with checking if the user is authenticated at all.

    My plan is to display "no access granted" instead of redirecting the user, but I assume this allows the user to update the "user" variable and just set the role through console.
  • 787770741868855327-@the_guy
    https://youtu.be/WUD1RLSd3U0?t=710

    I found this way on how to do it.
    It seems easy enough and similar to what I am doing with checking if the user is authenticated at all.

    My plan is to display "no access granted" instead of redirecting the user, but I assume this allows the user to update the "user" variable and just set the role through console.
    yoelfdz-1211779708510015598

    yoelfdz

    2 years ago

    Thx for sharing, will check it
  • the_guy01-1211780053566890136

    the_guy

    2 years ago

    If I understand correctly, encoding data into the JWT seems secure on its own as the encryption is done with a secret that is only stores server-side.

    To read a JWT, no secret is needed, only to verify if the JWT is from your AUTH system, you need the JWT and the secret.

    But how do I get the data from the encrypted JWT inside Toddle?
    @Lucas G

    Assuming I have stored the AUTH Token only in the Cookies.
    What else would I need to do to get data from the JWT?

    Just storing the User Object in Session or Local Storage is problematic since the user can just update it inside the Browser
  • lucasg-1211781080957456494

    Lucas G

    2 years ago

    If you set up custom claims in supabase, they are stored in the auth.users table under the app meta data which cannot be written to unless you are using service_key for example
  • Tod-1211781082630979704

    Tod

    2 years ago

    Great energy @Lucas G! Your continuous contribution to the toddle Community just made you advance to Community Level 21!
  • lucasg-1211781200297861121

    Lucas G

    2 years ago

    But they can be read via API via the auth endpoints
  • /auth/v1/user
  • In supabase, you'd set up the RLS policies to grant access if the JWT has the required claims in it
  • That thread may help
  • the_guy01-1211782122935681084

    the_guy

    2 years ago

    Ahh I see.
    It makes sense to add the roles to the RLS - it is also shown in the youtube video I shared earlier.

    Just trying to figure out how to go about the role based page/component authentication when the check has do be done clinet side
  • lucasg-1211782713082904607

    Lucas G

    2 years ago

    You can do it custom claims fairly easily since it is flexible in what you can store within it
  • Some people I think just choose to use user_profile tables and roles tables too
  • lucasg-1211783426114453625

    Lucas G

    2 years ago

    I shared a small video on that thread too, briefly went over how custom claims can be used
  • the_guy01-1211785334468386896

    the_guy

    2 years ago

    I thing I understood the concept of custom claims - seems like the way to go for role/feature based access.

    I understand that all RLS are updated instantly with new permissions, so the first request after the update is already wit the new permissions.

    When I want to do a Page/Component restriction on the client side - lets say a user can see the same page as an admin but the admin gets the "edit" button.

    I just fetch /auth/v1/user on page/component load - just once - and check for the role directly in the response without assigning the response to a variable and then checking the variable afterwards.
    Is this considered safe?
    Or can someone with just user access cheese his way into getting the edit button?

    I currently store the object I get as response on login on local storage - this can be read and updated by the user, so checking permissions from there is not safe.
    If I could get the Access Token that was stored as cookie and read the JWT it should be good.
    However, I would not be able to verify the JWT is actually from my system since I would expose the JWT secret due to missing secret management in toddle
  • the_guy01-1211786425872425020

    the_guy

    2 years ago

    When I think about it - IF the user is able to cheese his way into showing the Page/Component, the Page/Component would not provide any data as the data response is server side and uses the permissions from the auth.users.raw_app_meta_data

    So doing the RLS / server side permission check is mandatory, doing it on UI is cosmetics to only show UI to backend that the user would be authorized anyway.

    TLDR:
    If the user gets the "Edit Button" to show up an clicks it, nothing will happen because RLS does not allow to update a "user", only "admin" can update.
  • lucasg-1211786822347399199

    Lucas G

    2 years ago

    That about sums it up, yeah
  • lucasg-1211787170990395412

    Lucas G

    2 years ago

    If you're checking directly from the API response then a user would have to go through a good amount of loops to 'override' the response but even then they wouldn't actually be able to update anything on the backend as their JWT is signed from supabase by a secret that shouldn't be anywhere on the client side
  • the_guy01-1211788441642074222

    the_guy

    2 years ago

    I can see both options being valid:
    - fetch on every page load to get permissions for "instant updates"
    - fetch only on login to lower amount of API Calls done to backend

    I will go with the second one for now but consider the possibility to easily change it back/forth if required.