Switch to new API UI breaks my Supabase calls

  • mdxwired-1305925241289314317

    mdxwired

    5 months ago

    Hey all... So, with no other changes, an API setup that was working moments before the switch to the new API UI, now gives me this error instead:
    "JWSError (CompactDecodeError Invalid number of parts: Expected 3 parts; got 2)"

    To be clear, my authentication was working 100%, and then it wasn't. Any thoughts on this?
  • mdxwired-1305930223879061586

    mdxwired

    5 months ago

    Figured it out.

    By default, the previous methodology used to look for the JWT access token from login in the session cookies. Now, the new methodology defaults to looking for it in HTTP Only cookies. SO... one just needs to modify the auto-created API Bearer header to find the JWT in the correct place (session cookies).
  • lucasg-1305951020689522718

    Lucas G

    5 months ago

    Both APIs should use the same place πŸ€” can you clarify how you were storing it?
  • lucasg-1305951890361815173

    Lucas G

    5 months ago

    This is more for me to understand*
  • lucasg-1305952176417280022

    Lucas G

    5 months ago

    @Kedde shouldn’t they work the same or can you alleviate my ignorance 😬
  • andreasmoller-1305954285791481856

    Andreas MΓΈller

    5 months ago

    No they should work the same.
  • mdxwired-1305979644192751817

    mdxwired

    5 months ago

    Sadly, they do not for me. Also, the new methodology no longer seems to be passing my user id, which is breaking my policies on the database side. Is there some way in which I need to pass this more deliberately now?
  • mdxwired-1305979976885080188

    mdxwired

    5 months ago

    By "my user id" I mean the one that is successfully returned from my toddle-based Supabase login.
  • mdxwired-1305980738499248138

    mdxwired

    5 months ago

    1305980737920696370-image.png
    1305980738231078962-image.png
  • {"access_token":"xxxxxxxxxxxxxxObfuscatedxxxxxxxxxxxxxxxxxxxxxxx","token_type":"bearer","expires_in":3600,"expires_at":1731443652,"refresh_token":"h2oQFmesYqokInakEFkWVQ","user":{"id":"888deb53-4f88-4481-84dd-1e47cf2357b5","aud":"authenticated","role":"authenticated","email":"ssamples@somewhere.org","email_confirmed_at":"2024-08-18T02:42:49.232661Z","phone":"","confirmed_at":"2024-08-18T02:42:49.232661Z","last_sign_in_at":"2024-11-12T19:34:12.026143623Z","app_metadata":{"provider":"email","providers":["email"]},"user_metadata":{},"identities":[{"identity_id":"3e6dd4a1-745a-4f1d-86ff-fb4f42133662","id":"888deb53-4f88-4481-84dd-1e47cf2357b5","user_id":"888deb53-4f88-4481-84dd-1e47cf2357b5","identity_data":{"email":"ssamples@somewhere.org","email_verified":false,"phone_verified":false,"sub":"888deb53-4f88-4481-84dd-1e47cf2357b5"},"provider":"email","last_sign_in_at":"2024-08-18T02:42:49.224022Z","created_at":"2024-08-18T02:42:49.224081Z","updated_at":"2024-08-18T02:42:49.224081Z","email":"ssamples@somewhere.org"}],"created_at":"2024-08-18T02:42:49.216097Z","updated_at":"2024-11-12T19:34:12.041149Z","is_anonymous":false}}
  • mdxwired-1305981916209741963

    mdxwired

    5 months ago

    I had been using the in-built Authorization setup, rather than header-based, which was grabbing my session cookie just fine... and I did not seem to need to expressly send my user_id. Worked Great!! Not sure what I am doing wrong now after the UI switch.
    1305981915853094992-image.png
  • erikbeus-1305983882704719923

    Erik Beuschau

    5 months ago

    Hi @mdxwired
    What does your new API request look like? Does it include the Authorization header? In case you published any of the migrated APIs it's always possible to do a rollback.
  • mdxwired-1305985161590210561

    mdxwired

    5 months ago

    Yes, I got the Authorization header to work, by referencing the session cookie instead of the HTTP Only cookies. So, the Supabase server recognizes me as authorized... it is just not returning any records due to a policy that says

    on "public"."user_profiles"
    to authenticated
    using (
    (owner = auth.uid())
    );

    Which, again, worked fine right before I migrated. Not blaming anyone. Just assuming that I am doing something wrong now.
  • Somehow, the auth.uid is no longer being automatically 'picked up' from the access token. No clue why.
  • erikbeus-1305985556068700252

    Erik Beuschau

    5 months ago

    so your Authorization header looks something like this?
    1305985555875758131-Screenshot_2024-11-12_at_21.00.01.png
  • mdxwired-1305986435073183765

    mdxwired

    5 months ago

    Actually, when it looked like that, it did not work. Mine now looks like this...
    It does not show the variable in the interface, but seems to still be passing it, I think.
    1305986434485981237-image.png
  • Tod-1305986436561895425

    Tod

    5 months ago

    Great energy @mdxwired! Your continuous contribution to the toddle Community just made you advance to Community Level 7!
  • mdxwired-1305986535656652910

    mdxwired

    5 months ago

    1305986535367381083-image.png
  • mdxwired-1305986964876427285

    mdxwired

    5 months ago

    1305986964629098556-image.png
  • erikbeus-1305987589639110716

    Erik Beuschau

    5 months ago

    If you're storing the access_token in session storage, I guess it doesn't really make sense for you to use the Set session cookies action (which sets a cookie). Also, if you're using session storage, you need to be aware that the request cannot run during server side rendering (since session storage is only available in the browser). So you might want to disable SSR for your request (if that's currently enabled). It should still be possible to use our proxy although it's also not stricly needed if you have the token in session storage
  • mdxwired-1305988299785113715

    mdxwired

    5 months ago

    OK. So, to avoid all of this nonsense... where should I be storing my token so that the upgrades to th API containers will just work the first time? I can adjust the storage much more easily than trying to accommodate the way that I first learned.
  • ...instead of this:
    1305988437605875712-image.png
  • mdxwired-1305988797024178237

    mdxwired

    5 months ago

    Sorry. Frustrated because I followed a tutorial to get to where I got... and now it appears that was not where I should have been.
  • erikbeus-1305988933838180423

    Erik Beuschau

    5 months ago

    I would recommend:
    - Ensure you have the toddle browser plugin installed
    - Use the Set Session Cookies action that you already use to store the access_token cookie as an http-only cookie
    - Use the default Authorization header (similar to this screenshot https://discord.com/channels/972416966683926538/1305925241289314317/1305985556068700252)
    - Ensure you have proxying enabled for you API request
    - Hope it works 🀞
  • erikbeus-1305989005237686373

    Erik Beuschau

    5 months ago

    No worries. We're here to help πŸ™Œ
  • andreasmoller-1305989300315488278

    Andreas MΓΈller

    5 months ago

    The tutorials probably need an update πŸ™‚
  • mdxwired-1305989927930040351

    mdxwired

    5 months ago

    When I use the method indicated I get this:
    {"code":"PGRST301","details":null,"hint":null,"message":"JWT expired"}
  • lucasg-1305989935265878098

    Lucas G

    5 months ago

    Are there any tutorials that store access tokens in session storage?
  • andreasmoller-1305989997773455382

    Andreas MΓΈller

    5 months ago

    No.
  • lucasg-1305990011962921081

    Lucas G

    5 months ago

    That’s not best practice and I don’t think is recommended anywhere
  • lucasg-1305990092514660392

    Lucas G

    5 months ago

    Log back in
  • mdxwired-1305990197158219856

    mdxwired

    5 months ago

    Have done so numerous times. No longer seems to have the desired effect.
  • lucasg-1305990468840198305

    Lucas G

    5 months ago

    Sounds like something is off with how the token is being stored
  • mdxwired-1305990479330152529

    mdxwired

    5 months ago

    hang on... trying something else.
    🀞1
  • mdxwired-1305992931202695208

    mdxwired

    5 months ago

    So, here is the thing... I am not using 'session storage.' I am using 'session cookies', as indicated.

    Yet it does not seem to be working with the new Authorization Header.

    The toddle plugin has been installed the whole time. The only change is that I hit the 'upgrade' button, and what worked no longer works.

    I cannot quantify the problem any further.
    1305992930988658780-image.png
  • Was there something else that the old in-built auth was doing in addition to setting the Authorization header behind the scenes?
  • erikbeus-1305993185318928447

    Erik Beuschau

    5 months ago

    I've just updated my Supabase auth project here if you want to have a look at a reference implementation https://toddle.dev/projects/erik_auth/branches/main/components
    It's not possible to sign up in that project though since I've not setup email for my Supabase project, but let me know if you want an invite for the project so you can test it properly
  • 903997958196957254-@Erik Beuschau
    I've just updated my Supabase auth project here if you want to have a look at a reference implementation https://toddle.dev/projects/erik_auth/branches/main/components
    It's not possible to sign up in that project though since I've not setup email for my Supabase project, but let me know if you want an invite for the project so you can test it properly
    mdxwired-1305993512554074173

    mdxwired

    5 months ago

    Yes please. I am anxious to figure out what I am doing differently / incorrectly.
  • erikbeus-1305993543462162472

    Erik Beuschau

    5 months ago

    It's important that requests that use the Authorization header have "Proxy request" enabled. I don't think that happens automatically atm πŸ€”
    1305993543193464873-Screenshot_2024-11-12_at_21.31.22.png
  • erikbeus-1305993673712074764

    Erik Beuschau

    5 months ago

    Cool. Please send me a DM with your email and I'll send you an invite πŸ‘
  • mdxwired-1305993844483035240

    mdxwired

    5 months ago

    1305993844285767742-image.png
  • will do
  • lucasg-1305995725834031125

    Lucas G

    5 months ago

    That’s weird. There’s no reason for it to work when pulling from session storage
  • πŸ€”
  • mdxwired-1305996028692135967

    mdxwired

    5 months ago

    Sorry. I have never been using session storage. If I said so it was in error. I have always been using session cookies, as indicated.
  • mdxwired-1305996308192039022

    mdxwired

    5 months ago

    As such.
    1305996307973931039-image.png
  • erikbeus-1305996337522937868

    Erik Beuschau

    5 months ago

    I think we just got confused with this screenshot πŸ™‚ https://discord.com/channels/972416966683926538/1305925241289314317/1305986964876427285
  • lucasg-1305996610160951448

    Lucas G

    5 months ago

    Yes
  • mdxwired-1305996629563936909

    mdxwired

    5 months ago

    HA! Interesting... that actually IS the way that I was doing it... no idea why it worked. I am setting cookies but referencing storage. No clue.
  • My brain just saw what it expected to see after too many hours of staring at it.
  • Still, no idea why the correct method is not working if I am storing the token where I should be, which I think I am.
  • mdxwired-1306004525701926912

    mdxwired

    5 months ago

    SOLVED!!!

    Plugin had 'died.' πŸ’€
    That was all. It was installed, and running... but just not functioning for some reason. I uninstalled, rebooted, re-installed, and now everything is working exactly like it says on the tin. πŸ‘
    πŸ™Œ1
  • mdxwired-1306005367108407336

    mdxwired

    5 months ago

    I changed exactly nothing else and...
    1306005366898823210-image.png
  • lucasg-1306052653561937993

    Lucas G

    5 months ago

    Nice
  • Maybe it just needed to update to the newer version
  • Glad you got it solved