hmmm, stuck in an infinite loop calling /self-info
a
hmmm, stuck in an infinite loop calling /self-info
r
Hey! Let’s talk in this thread.
a
yup
so, it looks like self-info never gets hit
because it's behind an authorizer
r
right. So debug logs from the authorizer?
a
Session does not exist anymore
Copy code
{
  type: 'UNAUTHORISED',
  message: 'Session does not exist anymore',
  payload: { clearCookies: true },
  errMagic: 'ndskajfasndlfkj435234krjdsa',
  fromRecipe: 'session'
}
r
So the debug logs will tell you why. But i suspect that the browser is not sending the cookies - what is the request headers of that request?
a
Copy code
:authority: api.dev.makesweft.com
:method: GET
:path: /auth/self-info
:scheme: https
accept: application/json, text/plain, */*
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
authorization: null
cookie: sAccessToken=...; sAccessToken=...; sIdRefreshToken=...
origin: https://dev.makesweft.com
referer: https://dev.makesweft.com/
rid: anti-csrf
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="104"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Linux"
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-site
user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.5112.101 Safari/537.36
the cookies are there with the encoded payloads
replaced with ... by me
r
hmm. Whats odd is that there are two
sAccessToken
.
Is it possible that the cookies are not reaching the lambda authorizer?
a
let me clear my cookies and see if I can reproduce
r
okay
a
oh
I have 2 cookies
one from api.dev.makesweft.com and one from .dev.makesweft.com
which is why you see two in the header
r
ah right.
i mean that should not cause issues anyway
it would be most helpful if you can enable debug logs in the lambda authoriser and show its output
a
I have it
let me try to reproduce by signing out, which is what causes this, I think
r
okay
a
nope. Can't reproduce
works fine
I think somehow signout failed to clear my cookies?
but I'm not sure why that would cause an infinite loop
yeah, signing out now completely clears my cookies, no issues
r
hmmmm.
Well, if it happens again, you can send over the debug logs
a
this is what the logs had
Copy code
2022-09-01T05:40:05.918Z com.supertokens {t: "2022-09-01T05:40:05.918Z", message: "getSession: Started", file: "/var/task/node_modules/supertokens-node/lib/build/recipe/session/recipeImplementation.js:135:26" sdkVer: "11.3.0"}
2022-09-01T05:40:05.919Z com.supertokens {t: "2022-09-01T05:40:05.918Z", message: "getSession: rid in header: true", file: "/var/task/node_modules/supertokens-node/lib/build/recipe/session/recipeImplementation.js:136:26" sdkVer: "11.3.0"}
2022-09-01T05:40:05.919Z com.supertokens {t: "2022-09-01T05:40:05.919Z", message: "getSession: request method: get", file: "/var/task/node_modules/supertokens-node/lib/build/recipe/session/recipeImplementation.js:137:26" sdkVer: "11.3.0"}
2022-09-01T05:40:05.919Z com.supertokens {t: "2022-09-01T05:40:05.919Z", message: "getSession: Value of doAntiCsrfCheck is: false", file: "/var/task/node_modules/supertokens-node/lib/build/recipe/session/recipeImplementation.js:190:30" sdkVer: "11.3.0"}
2022-09-01T05:40:05.919Z com.supertokens {t: "2022-09-01T05:40:05.919Z", message: "getSession: Success!", file: "/var/task/node_modules/supertokens-node/lib/build/recipe/session/recipeImplementation.js:213:30" sdkVer: "11.3.0"}
Copy code
2022-09-01T05:40:06.019Z    961d9058-ef0f-4385-b4ea-564ac233222c    INFO    SessionError {
  type: 'UNAUTHORISED',
  message: 'Session does not exist anymore',
  payload: { clearCookies: true },
  errMagic: 'ndskajfasndlfkj435234krjdsa',
  fromRecipe: 'session'
}
2022-09-01T05:40:06.019Z    961d9058-ef0f-4385-b4ea-564ac233222c    ERROR    Invoke Error     {
    "errorType": "Error",
    "errorMessage": "Unauthorized",
    "stack": [
        "Error: Unauthorized",
        "    at Runtime.exports.handler (/var/task/index.js:49:19)",
        "    at runMicrotasks (<anonymous>)",
        "    at processTicksAndRejections (node:internal/process/task_queues:96:5)"
    ]
}
Is this helpful for you?
r
Hmm. It says "getSession: Success!" -> so this means that something else is throwing UNAUTHORISED.
a
@rp_st - it happened again this morning
getSession success
getSessionData UNAUTHORISED Session does not exist anymore
r
Ohhh right. So are you calling getSessionData on your api layer?
I mean in your lambda functions
And not in lambda authoriser
a
that's in the lambda authorizer
r
Can I see the code in your lambda authoriser?
a
Copy code
exports.handler = async (event) => {                                            
    console.log("we have entered lambda");                                      
    try {                                                                       
        console.log("calling Session.getSession...");                           
        const session = await Session.getSession(event, event, { sessionRequired: false });
                                                                                
        console.log("...Session.getSession returned: ", session);               
        if (session) {                                                          
            console.log("calling session.getSessionData()...");                 
            const sessionData = await session.getSessionData();                 
            console.log('session data: ', sessionData);                         
            const { credentialsEmail } = sessionData;                           
            const claims = {                                                    
                available: true,                                                
                email: credentialsEmail,                                        
            };                                                                  
            console.info("session present");                                    
            // We need to add setCookie to the context, since later we will be mapping this to a Set-Cookie header on the response
            // getSession has to set cookies on the first call after a refresh. 
            return generateAllow(session.getUserId(), event.methodArn, {        
                setCookie: event.supertokens.response.cookies.join(', '), // Consider removing this
                ...claims,                                                      
            });
r
Right. So the console log for calling getSessionData is printed out? And right after that, that function throws an error for unauthorised?
a
yup, it throws on session.getSessionData
we don't see "session data: " in the logs
r
So that means something had revoked the session by the time the getSessionData function is called. Now the reason why getSession still succeeds is cause it does statelsss verification
So is there a revokeSession that happens somewhere? Or a user logout?
a
user logout
r
So that’s why that function throws that error.
So a user logout should also clear the cookies
Is clearing the cookies not happening?
a
it looks like it's not
I have 2 cookies again this morning
r
Hmm. Can you send me a screenshot of the response headers of the sign out request?
a
hmmm, I can't find it
that's strange
I had to go to our /logout route twice before it would clear the cookie
and I signed back in and WSOD again
oh wow, the cookies are thrashing
r
So it’s calling the signOut api?
When you visit the /logout page,
? *
a
I actually don't know, I think the console is clearing
r
There should be a preserve network requests / logs buttons somewhere
a
ok
access-control-allow-credentials: true access-control-allow-headers: Content-Type, rid, fdi-version, anti-csrf access-control-allow-methods: OPTIONS,POST,GET,PUT,DELETE access-control-allow-origin: https://dev.makesweft.com access-control-expose-headers: id-refresh-token content-length: 15 content-type: application/json context-type: application/json date: Thu, 01 Sep 2022 13:38:30 GMT id-refresh-token: remove set-cookie: sAccessToken=; Domain=.dev.makesweft.com; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT; HttpOnly; Secure; SameSite=None set-cookie: sRefreshToken=; Domain=.dev.makesweft.com; Path=/auth/auth/session/refresh; Expires=Thu, 01 Jan 1970 00:00:00 GMT; HttpOnly; Secure; SameSite=None set-cookie: sIdRefreshToken=; Domain=.dev.makesweft.com; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT; HttpOnly; Secure; SameSite=None vary: Origin x-amz-apigw-id: XyFZfEVPiYcFSwg= x-amzn-requestid: 141956fd-4c48-4b60-928a-124ea54cfeaa x-amzn-trace-id: Root=1-6310b5d6-114d5ff84c185db160360ebc;Sampled=0
r
Ok so it does clear the cookies
After this, what does the cookie store look like?
Ok. That’s correct state
If you visit the domain for your api on the browser, what does the cookie store there look like?
Ahh I see. So something is setting that access token to a different domain
Which is why it exists
a
ok, so I need to get rid of the api. one, yes?
as in never let it get set, right?
r
Yes. That shouldn’t be there (unless there is some misconfigured on the backend)
There should be just one sAccessToken whose domain is .dev.makesweft.com (which got cleared from the sign out request)
So you might want to see what might be adding this cookie in the first place. Fixing that part should prevent this type of issue altogether
a
thanks, that's helpful
Appreciate the support, Rishabh
r
Happy to help 🙂 lmk if it persists. I’ll be happy to jump on a call
a
I think I see where it's being set
what is the intended value of "MICROSERVICE_DOMAIN" ?
r
I’m not sure what you mean
There isn’t any config like that that we have
a
hmmmm
OH, ok
that value gets fed to apiDomain
what is the intended value of apiDomain?
r
Ah right.
So it should be the actual be the domain part of your api. In this case, that should be api.dev.gosweft.com
a
ok, that's what it is
r
Now that would set the cookie domain to be that by default. Unless you provide the cookieDomain config in session.init on the backend
a
so cookieDomain needs to be set with the leading dot, correct?
so api.dev.gosweft.com should become .dev.gosweft.com
r
Yes, for the cookieDomain value (not for the apiDomain) That is if you want to share the cookies across multiple api domains.
If you don’t want to share with multiple api domains and only with api.dev.gosweft.com, then just don’t set cookieDomain in session.init
a
got it
ok, I'm having trouble reproducing the behavior
so I'll put these changes in and report back if it happens again
r
Cool
d
Short question for the Supertokens gurus: 1. User "u1" has a valid session and is able to call an API which is "guarded" by verifysession. 2. All sessions for "u1" will be revoked at the dashboard. 3. "u1" is calling an API and will get immediately a 401 (Message: Session does not exist anymore). I wonder why does this happen immediately (access_token_blacklisting = false)? I thought that should only happen when the access token validity has been expired.
r
Do you use session.getSessionData function? Or session.updateSessionData function?
d
I don't think so - at least not consciously. Is claim validation internally using that?
r
Are you calling session.mergeIntoAccessTokenPayload?
d
No, and the API call just doing this:
Copy code
@Get('/info')
@UseGuards(STAuthGuard)
  async getSessionInformation(@Session() session: SessionContainer) {
    return {
      userId: session.getUserId(),
    };
  }
Is the "node-server" somehow caching the id of the session handler which have been revoked?
And this is the corresponding log:
r
So it's happening in the claim validators - "checking shouldRefetch for struggly-sv"
so this seems like a custom claim you added? The shouldRefetch function returned true, which then caused a call to session.mergeIntoAccessTokenPayload which then queried the core, which then found that the session did not exist and therefore this error is thrown
d
Ah, this makes sense. Yep, struggly-sv is a custom claim! Thanks!!!!!
2 Views