You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently if you revoke the session in a refreshSession function override it still returns 200 and sets the session tokens in the response, while doing the same in the API override will not set the tokens.
This is because the session object doesn't save the fact that it has been revoked and the default API impl can set the tokens in the response.
If the user wants to deny refreshing the session they should throw an UNAUTHORISED error after revoking the session.
Internal discussions: https://supertokens.slack.com/archives/C03J31QAQLC/p1699977428029849
Summary: this can be fixed by making revokeSession save the "revocation" on the session object and to make attachSession.. and the refreshSession API impl handle it appropriately. Although the current impl is not ideal, we decided to postpone fixing, since there is a straightforward "workaround" and it's a rare use-case anyway.
The text was updated successfully, but these errors were encountered:
This can also be achieved by overriding the api layer instead of the functions layer, and revoking the session after calling the original implementation of the refresh API.
Currently if you revoke the session in a
refreshSession
function override it still returns 200 and sets the session tokens in the response, while doing the same in the API override will not set the tokens.This is because the session object doesn't save the fact that it has been revoked and the default API impl can set the tokens in the response.
If the user wants to deny refreshing the session they should throw an
UNAUTHORISED
error after revoking the session.Internal discussions: https://supertokens.slack.com/archives/C03J31QAQLC/p1699977428029849
Summary: this can be fixed by making revokeSession save the "revocation" on the session object and to make
attachSession..
and therefreshSession
API impl handle it appropriately. Although the current impl is not ideal, we decided to postpone fixing, since there is a straightforward "workaround" and it's a rare use-case anyway.The text was updated successfully, but these errors were encountered: