supabase-kt icon indicating copy to clipboard operation
supabase-kt copied to clipboard

[Feature request]: A method to require requests to be authenticated

Open sproctor opened this issue 6 months ago • 4 comments

General Info

  • [x] I installed the latest version of Supabase Kt
  • [x] I checked for similar feature requests

Feature request

If the session refresh fails, it's possible to send requests with the anon token by accident.

Usecase

It's very hard or impossible to distinguish between genuine permission issues and a request being sent with the anon token. It would be ideal to have a flag in the Postgrest feature install that would cause requests to fail with a unique exception when not authenticated.

This can be checked directly before sending the request, but that creates a race condition.

sproctor avatar Jun 16 '25 15:06 sproctor

Not sure if it makes sense to have this flag only in Postgrest, as you could also add this in the other modules

jan-tennert avatar Jun 22 '25 10:06 jan-tennert

After 15 minutes of staring, I still don't see where the JWT is added.

I'm trying to figure out what exactly happened to cause this bug. It's entirely possible it's something on my end. The user was logged in, somehow their JWT disappears and a request is sent with the anon key. Is it possible for this to happen without explicitly removing the JWT on the application side or logging out? It's possible the user logged out and my application made some requests after. I don't think that's the case, but it's a possibility.

My problem is that sending a request with the anon key causes a what looks like a server/schema error. For me, the ideal would be to leave the old JWT in place (if it's indeed removed due to being expired) and check if it's expired before sending a request and return an error in that case, or try the request with the expired JWT.

sproctor avatar Jul 16 '25 22:07 sproctor

Is it possible for this to happen without explicitly removing the JWT on the application side or logging out

The only instances where the session is removed by the client are: there was an error response upon refreshing https://github.com/supabase-community/supabase-kt/blob/7a690b0ce2e748445883cd064acf8b066a10cbe9/Auth/src/commonMain/kotlin/io/github/jan/supabase/auth/AuthImpl.kt#L476-L481 there was an session not found error on any request (session deleted) https://github.com/supabase-community/supabase-kt/blob/7a690b0ce2e748445883cd064acf8b066a10cbe9/Auth/src/commonMain/kotlin/io/github/jan/supabase/auth/AuthImpl.kt#L570-L576

There is no other instance. It does get set to RefreshFailure when the session is expired and it failed to refresh while it already expired, but thats only for the status, the session itself does not get cleared but is also not really usable as it definitely expired. If this status appears, you can also be sure that the client tries to refresh it, otherwise this status wouldn't appear.

Edit: The access tokens are resolved here https://github.com/supabase-community/supabase-kt/blob/7a690b0ce2e748445883cd064acf8b066a10cbe9/Auth/src/commonMain/kotlin/io/github/jan/supabase/auth/AccessToken.kt#L33-L36

jan-tennert avatar Jul 17 '25 14:07 jan-tennert

I'll be adding an option for this next release.

jan-tennert avatar Oct 12 '25 00:10 jan-tennert