-
-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: disallow setSession loophole #536
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hey @j4w8n, thanks for making the time to fix this issue for us! just left a few comments but overall, it lgtm!
thanks for making the changes! i'm marking this as a |
🎉 This PR is included in version 2.4.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
What kind of change does this PR introduce?
I managed to jack up my fork, so have to resubmit this.
Adds checks for the passed-in
access_token
. Also refactorssetSession()
, to align the method with common behaviors of other methods.What is the current behavior?
Some people, including myself, are passing in an empty string for the access token, to force a session refresh even if the session isn't expired. There is now a
refreshSession()
method to accomplish this, as of supabase-js version 2.0.4What is the new behavior?
Checks if the access token is an empty string. Also adds a regex check to the
decodeJWTPayload()
helper, to verify the access token is in base64url format; otherwise we could still pass in something likehello.there.world
and we'd get the same forced refresh behavior.As for the refactor, I noticed that this method is directly calling
_refreshAccessToken()
then calling_saveSession()
. However,_callRefreshToken()
is used on other methods; and is a better fit, since it seems to handle multiple refresh calls. Plus it calls_saveSession()
itself, which eliminates the need for that call insetSession()
.Additional context
Closes #490