PricingBlog

Supabase auth strategy

  • aburio-1265681200865873970

    Aburio

    1 year ago

    I checked both these videos about Supabase (https://youtu.be/SHJ3EadcrgY?si=5p_5s9TPCUliOyy0 and https://youtu.be/Ol-rANqDclI?si=tfzy2mUyrbjf1x1U) but I didn't find how I can protect pages from unauthenticated users and how I can automatically redirect already authenticated users to the right page if they try to access the login page.

    For the restricted access pages, should I make a Supabase call "on load" and, in case of a "token error," redirect them to the login page?
    For the already authenticated users who land on the login page, should I make the login API call on load and redirect them on success?
  • building_stuff-1265684422535942198

    Janis

    1 year ago

    Here's what I'm doing (not sure if its best practice but it works for me)

    I have a wrapper-component that wraps the entire page and is only shown when the authentication call to Supabase is successful. And yes, you can simply fetch the current user on page load
    1265684422049665217-image.png
  • In your API call you can set an On Error event that redirects the unauthenticated user to your login page
    1265684600039149663-image.png
  • For redirecting authenticated users from the login page to your page you can do the same thing but the other way around: When your auth api call is successful, then redirect to /app
  • stockton_f-1265687438194512015

    Stockton

    1 year ago

    This is basically how I do it to @Janis 🙌

    You gave me an idea though...

    Make the login screen a component and show that component when auth errors.

    Show the page when it's success, show the login component when it's failure.

    I'm going to try it, because most people redirect to a login screen, but imagine being able to log in and stay on the same page... no one does that.

    Unless there's some like security risk or something?
    👍1
  • aburio-1265688385511489579

    Aburio

    1 year ago

    @Janis thank you it make sense !
    @Stockton I thing It can be risky be cause I'm not sure if the Show attribute is evaluated on server side or client side. If it's client side it can be possible that a user can access the page without login by looking at the HTML code of the page.
    🙏1
  • lucasg-1265688772452814931

    Lucas G

    1 year ago

    Unless it's a static site where the content you are trying to protect isn't being pulled from a database elsewhere, best practice is always to secure things on database side
  • So even if a user sees some of the page, there won't be any data on it
  • Wordpress and a few other platforms do the login modal
  • Most of the time you still have to at least refresh the page
  • But it's better than double redirect I guess
  • stockton_f-1265689256668561409

    Stockton

    1 year ago

    Right, so assuming that the content of the page is fetched via an API request that requires authorization.

    On login, Re-call the API to get the content, Toddle will refresh the content without refreshing the page.
  • lucasg-1265689767924858991

    Lucas G

    1 year ago

    Should work, yeah
  • aburio-1265696612420681789

    Aburio

    1 year ago

    @Lucas G ok thank you for the feedback. The big question is how we can refresh the supabase token so user stay logged-in ?
  • lucasg-1265698175491248263

    Lucas G

    1 year ago

    Change the expiry time on supabase settings
  • toddle handles some of the refresh stuff on its own but you can do it yourself using the user’s refresh token
  • mighty.13-1265699390937501736

    Mighty

    1 year ago

  • aburio-1265701816071487591

    Aburio

    1 year ago

    Are you sure that Toddle refreshes the token for us? From my understanding, they put a max-age of 24 hours on the token and refresh token, but they don't refresh it for us. Maybe @Andreas Møller or @Erik Beuschau can clarify that?

    @Mighty, that's what I'm trying to do, but I don't know how to access the refresh token in the session cookie from the formula or workflow editor 🥲
  • andreasmoller-1265702013220421695

    Andreas Møller

    1 year ago

    No toddle does not refresh the token yet.
  • lucasg-1265702120749793350

    Lucas G

    1 year ago

    I do not remember exactly. I remember Andreas talking about it but dont know if a 'to-come' thing or actually a thing. I could be wrong on that
  • Ah
  • There you go
  • aburio-1265702376334037173

    Aburio

    1 year ago

    @Andreas Møller the only way to access the session cookie is by using a custom action ? Or can we do it by a formula ?
  • lucasg-1265702447825948767

    Lucas G

    1 year ago

    I set the expiry on supabase side settings though and don't have issues with having to login often
  • I don't think toddle caps expiry at 24hrs
  • aburio-1265702683298500749

    Aburio

    1 year ago

    Yes but It makes no sense to force people to login again when you have stored the info to refresh it 😄
  • mighty.13-1265702756560277586

    Mighty

    1 year ago

    Can you crerate an API with post, and then call the api request from the workflow?
  • Tod-1265702763682201813

    Tod

    1 year ago

    Great energy @Mighty! Your continuous contribution to the toddle Community just made you advance to Community Level 1!
  • lucasg-1265702767540834453

    Lucas G

    1 year ago

    You can refresh it yourself, yeah
  • andreasmoller-1265702801338798150

    Andreas Møller

    1 year ago

    You cannot access the cookie outside of an API request.
  • lucasg-1265702819785347082

    Lucas G

    1 year ago

    cookies are not accessible, they are HTTPS cookies
  • not by client-side JS
  • andreasmoller-1265703011242741832

    Andreas Møller

    1 year ago

    Exactly
  • lucasg-1265703208622493788

    Lucas G

    1 year ago

    When you get the user from supabase, you can also get the refresh token
  • aburio-1265704209295347793

    Aburio

    1 year ago

    Yes, but how can I access it afterward? Because I can set the session cookie but not read it.
    Sorry for all my questions... I'm a bit lost!
  • aburio-1265706003928711293

    Aburio

    1 year ago

    Ok I found the answer 🥲
    1265706003832246352-Capture_decran_2024-07-24_a_18.23.25.png
  • lucasg-1265711031821271202

    Lucas G

    1 year ago

    That's what I was saying. You can adjust it in supabase settings
  • lucasg-1265711333211635753

    Lucas G

    1 year ago

    If you REALLY need, you could maybe set up a read-only table where you store the refresh token (via a backend server) from where only that user can read it and call it from there
  • Not sure how ideal it would be but with good RLS, it should be ok
  • aburio-1265923966103719962

    Aburio

    1 year ago

    Ok so finally I choose to go all-in client side with the supabase-js library and custom actions. As soon as we get a way to set and get session cookie I will migrate back to SSR API
  • andreasmoller-1265924500894126121

    Andreas Møller

    1 year ago

    You. Can already set the session cookie. If you need a way to read the current user session, we use a supabase sql function for returung the current user
  • aburio-1265927759348109355

    Aburio

    1 year ago

    When I say "Set and get session cookie," what I meant is being able to store more than just the access_token. Regarding using a custom Supabase function to get the current session, this still doesn't solve the refresh token process because if your access_token is expired, you cannot get the current session. If you can, this sounds like a security breach.
  • aburio-1265973721433378857

    Aburio

    1 year ago

    Ok so my final solution is :
    - Login from API call, if success we store the access_token in cookie and the refresh_token in local storage
    - On my protected page, on loading I do a Get User API call and if I got an error about token missing, I try to refresh using the token from the local storage and if fail you go back to the login page.