https://supertokens.com/ logo
Title
n

Nabeel

11/04/2022, 5:25 AM
Hello all once again, [context] We are using the goland-SDK with thirdpartypasswordless recipe , and self-hosted supertokens core As per https://supertokens.com/docs/session/quick-setup/backend#5-add-session-verification-to-your-api we also have exposed the /sessioninfo api which is returning the user data if the Cookies (sAccessToken , sIdRefreshToken) is valid otherwise results in error Now, the situations is this (the following is done via postman calling the APIs): we have called the /auth/signout API with the concerned Cookies, and this has removed the session_handle entry from the session_info table in the database. However, even after this signout , we are calling the /sessioninfo API with the same Cookies (whose session ideally should have been revoked) and the SDK itself is validating the session, thereby returning the 200 status code (which ideally should have been unauthorised) Note: However the /auth/session/refresh API is returning unauthorised on calling with the signed-out cookies
r

rp

11/04/2022, 5:27 AM
Hey!
Are the cookies not being cleared on the frontend when you call sign out?
Also, the session info api is just an example in the docs. You don’t need to add it to your app
n

Nabeel

11/04/2022, 5:33 AM
Hey, First of all thanks for prompt response and as far as clearing of cookies, Yes they are being cleared on calling sign out however, I have deliberately added the Cookie header with the sAccessToken and sIdRefreshToken in the postman request, and those cookies are getting verified in the API Moreover, I am also referring /sessioninfo API as example because in this , first the Cookies are getting verified in the middle ware and then the further procedure is getting done we are using the
session.VerifySession(options, func(rw http.ResponseWriter, r *http.Request) {
            c.Request = c.Request.WithContext(r.Context())
            c.Next()
        })(c.Writer, c.Request)
        // we call Abort so that the next handler in the chain is not called, unless we call Next explicitly
        c.Abort()
function of session package in our authenticate middleware, the this function isn't invalidating the cookies of the signed-out session
r

rp

11/04/2022, 5:34 AM
ah i see.
So session verification is stateless in SuperTokens
thats why it still works
but since access tokens are short lived, when they expire and if you try the refersh API with the refresh token, that will fail
You can enable access token blacklisting though: https://supertokens.com/docs/session/common-customizations/sessions/access-token-blacklisting And this will make session verifications fail instantly
but the downside is is that each API verification will be slower cause of network requests.
n

Nabeel

11/04/2022, 5:37 AM
got it!!! thanks for pointing the other option and the trade-offs