Closed Cegoco11 closed 5 months ago
It did exist previously, but was not functionality mirrored upstream and so was removed.
You are correct that the access_token
is a short lived resource whereas the refresh_token
is long lived and I agree with the direction of your idea!
However, the current state of the auth docs and the js client both require that you have an access_token
and a refresh_token
(see docs here, see JS client code ref)
Interestingly (and to your point), it looks like you don't explicitly need the access_token
to make the API call as while the JS client enforces that you do, the actual api call seems to only require the refresh_token
.
But, as this library is modeled after the JS client, we try our best to mirror its API, so, because the JS client does not expose this publicly, the C# client will not either.
Thank you for the quick response!
So the workaround could be that we have the access_token
available, then call the equivalent of setSession
in the JS Client but in the C# package. (Which I assume it is GetSessionAsync
)
This way we will be able to call the RefreshSession
being the CurrentSession
object populated and being able to go forward in this.
Did I got you right?
Close! We actually have a SetSession(string access_token, string refresh_token)
on the client as well. But yep, you'll just need to have the access_token
available!
Thank you very much for your help, I'm closing this one!
Feature request
Is your feature request related to a problem? Please describe.
Currently, we found some difficulties refreshing tokens in our web app. We use a custom middleware with scoped lifetime to handle multiple users, being the client a non persistent session. So, trying to get a new access token using the refresh cookie is not possible, pointing us to a "Not Logged in." error. (We haven't dive a lot into the code, so maybe there are more conditions and not just this method)
Describe the solution you'd like
We would like to be able to refresh access tokens using the refresh token cookie, without the need of the access token. We think that access tokens are usually short-lived resources and refresh tokens long-lived. That's why we are not understanding the need of the access token since the expiration will not be the same.
Describe alternatives you've considered
None, as we do not have the session saved.
Additional context
We noticed that this behavior was previously implemented in the code. We don't know if this was a bug or not, that's why we are creating this as a new feature request.
https://github.com/supabase-community/gotrue-csharp/commit/b097c343b4a0fe756565bf8b59dee3db6ebae804#diff-61e34891b161dc56627598f4dd0d09c704317ca492f3708b5b22627a40633777
Thanks in advance!