I have a controller defined as follows:

import { Controller, Get, Query, Session, UseGuards } from '@nestjs/common';
import { SessionContainer } from 'supertokens-node/recipe/session';

import { BasicAuthGuard } from '../auth/guard/base-auth.guard';
import { GetSubscriptionDetailsRequestDto } from './dto/get-subscription-details.dto';
import { PaymentsService } from './payments.service';

function getUserEmailFromSession(session: SessionContainer) {
  const { email } = session.getAccessTokenPayload();
  return email;
}

@UseGuards(BasicAuthGuard)
@Controller('payments')
export class PaymentsController {
  constructor(private readonly paymentsService: PaymentsService) {}


  @Get('details')
  public async getSubscriptionDetails(
    @Session() session: SessionContainer,
    @Query() input: GetSubscriptionDetailsRequestDto,
  ) {
    const subscriptionDetails = await this.getSubscriptionDetailsFromEmail(
      getUserEmailFromSession(session),
    );
    return subscriptionDetails;
  }
}

Here's the code for the auth guard

import type { CanActivate, ExecutionContext } from '@nestjs/common';
import { Error as STError } from 'supertokens-node';
import { verifySession } from 'supertokens-node/recipe/session/framework/express';

export class BasicAuthGuard implements CanActivate {
  constructor() {}

  public async canActivate(context: ExecutionContext): Promise<boolean> {
    const ctx = context.switchToHttp();

    let err = undefined;
    const resp = ctx.getResponse();
    // You can create an optional version of this by passing {sessionRequired: false} to verifySession
    await verifySession({ checkDatabase: true, sessionRequired: true })(
      ctx.getRequest(),
      resp,
      (res) => {
        err = res;
      },
    );

    if (resp.headersSent) {
      throw new STError({
        message: 'RESPONSE_SENT',
        type: 'RESPONSE_SENT',
      });
    }

    if (err) {
      throw err;
    }

    return true;
  }
}

This controller runs fine 95% of the time. But we're seeing a weird log on our servers that shouldn't be there.

ALERT!!!! INTERNAL SERVER ERROR!!!
            STATUS: 500
            METHOD: GET
            PATH: /payments/details?checkoutCancelPath=%2Fbilling&checkoutSuccessPath=%2Fbilling&portalReturnPath=%2Fbilling
            REQUEST-ID: 492f101b-92e4-4762-8a82-4f131c995c3f
            MESSAGE: Cannot read properties of undefined (reading 'getAccessTokenPayload')
            ERROR: 'Unhandled Rejection'
            STACK: TypeError: Cannot read properties of undefined (reading 'getAccessTokenPayload')
    at PaymentsService.getUserEmailFromSession (/app/dist/modules/payments/payments.service.js:187:35)
    at PaymentsController.getSubscriptionDetails (/app/dist/modules/payments/payments.controller.js:27:37)
    at /app/node_modules/@nestjs/core/router/router-execution-context.js:38:29
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async /app/node_modules/@nestjs/core/router/router-execution-context.js:46:28
    at async /app/node_modules/@nestjs/core/router/router-proxy.js:9:17

And I have no clue as to what is happening on the FE that's causing this. We've been unable to identify which user is having this issue. The authentication method is cookies, the access token is sent in the 'cookie' header. I would really appreciate if anyone can give insights into why we're getting a

session

that's

undefined

. In my limited knowledge, if the cookie header is not present the BasicAuthGuard should already throw a 401, and I've tested this manually and it is indeed the case. What escapes me is how can a request pass through the auth guard successfully and end up having a session that is

undefined

Thanks allot!

Have you added the supertokens error handler to your application?

this step: https://supertokens.com/docs/thirdpartyemailpassword/nestjs/guide#add-the-supertokens-error-handler

Absolutely! they work perfectly.

Cause verifySession will send a response in case the access token is expired or doesn’t exist. In which case, the if(resp.headersSent) should be true

Where are you calling the getAccessTokenPayload function? Maybe there is some other issue? Like the session does exist, and is passed in the API as an input, but somewhere in your logic it gets set to undefined?

@rp_st if you look at the code I have pasted. There's a function called

getUserEmailFromSession

it uses the access token payload to get the email of the user. That's where we're calling

getAccessTokenPayload

Look at the stack trace to get a clear picture.

Can you make an api call to this endpoint without an access token? What happens?

Can you create a session, save the access token somewhere, then revoke the session in offline mode, and then call the api with the saved access token? What do you get?

@rp_st ^

hi @rp_st So this is what I did. I logged in using the FE. And I went to the page that makes this api call. I coped the api call as curl and tried it in postman, it worked and returned a 200. I then logged out of the FE. And went back to Postman to try this again, and I got a 401. And the server logs just show this log.

err: {
      "type": "SuperTokensError",
      "message": "RESPONSE_SENT",
      "stack":
          Error: RESPONSE_SENT
              at BasicAuthGuard.canActivate (/Users/muhammadsalarkhan/Repos/Apollo/venus-api/src/modules/auth/guard/base-auth.guard.ts:27:13)
              at processTicksAndRejections (node:internal/process/task_queues:95:5)
              at GuardsConsumer.tryActivate (/Users/muhammadsalarkhan/Repos/Apollo/venus-api/node_modules/@nestjs/core/guards/guards-consumer.js:16:17)
              at canActivateFn (/Users/muhammadsalarkhan/Repos/Apollo/venus-api/node_modules/@nestjs/core/router/router-execution-context.js:134:33)
              at /Users/muhammadsalarkhan/Repos/Apollo/venus-api/node_modules/@nestjs/core/router/router-execution-context.js:42:31
              at /Users/muhammadsalarkhan/Repos/Apollo/venus-api/node_modules/@nestjs/core/router/router-proxy.js:9:17
      "errMagic": "ndskajfasndlfkj435234krjdsa"
    }

Which means the request was declined by the auth guard and it didn't even goto the service.

Hmm. So the code seems fine

The best course of action now may be to just add some debug logs perhaps. So in the place where you use the getAccessTokenPayload function, before that, check if session is undefined, and if it is, log some helpful messages: like the headers in the request for example.

Should I also log the current unix timestamp for some reason?

🙂 *

So this makes sense as to why your API was called.

But, still, req.session should always be there

did anything get logged based from this change?

hmm

can you send another request to that env with the exact same request headers?

But I think its moot at this point the access token must have expired

or maybe use a new access token and keep the other headers the same

@rp_st I got a 200 OK response with the new access token

here is where the req.session is set: https://github.com/supertokens/supertokens-node/blob/master/lib/ts/recipe/session/framework/express.ts#L31

but actually, our docs does have (https://supertokens.com/docs/thirdpartyemailpassword/nestjs/guide#add-a-session-verification-guard):

if (err) {
      throw err;
    }

In the auth guard. So hmm. I don't think thats the issue either

and if verifySession is doing its job correctly, why is it able to come to the conclusion that the request is authenticated, but is not able to attach a proper session object to the request. I believe it is `verifySession`'s responsibility to attach the session container to the context right??

I still think the issue might be that the core is throwing a 500 error and that’s not being handled properly in the nestjs integration we have. Even though it seems like it is.

@porcellus could you test this out please?

I'll test this out manually a bit later today, but as far as I can see the only path where

verifySession

doesn't attach the session object is where it encounters an error, but then handles it by sending a response. Right now I have 3 main theories: 1.

ctx.getRequest

returns different objects in some cases (which would be very weird from NestJS) 2.

verifySession

encountered an error and then handled it by sending a response. By some race condition/timing issue, however it hasn't been actually sent, so the

headersSent

check doesn't catch it. (I'll do further checks to see if/how this can happen, but it'd explain all symptoms) 3. there is some bug in

verifySession

that only happens in some weird timing.

As far as I can see this cannot happen because of the core returning a 2XX as we handle anything non-200 as an error and a 200 response with missing props would handled as either as a TRY_REFRESH_TOKEN error or construct the session object (or throw while constructing the session object)

I've manually tested: 1. Core responding with 400&500 (the handling is the same for any non-200): this always results in a 500 error returned from the backend (the AuthGuard throws) 2. Modifying core responses to remove some/all props from the getSession response: this also works as expected: in some cases it continues working, in other cases we get a 401 response.

As my current best guess is #2 from the above list, I've reviewed the code to check if we missed any awaits or ignored any promises returned during error handling and I could find anything. Still, this is my most likely candidate.

One way you could try to get around it is to update

BasicAuthGuard

like this:

ts
import type { CanActivate, ExecutionContext } from '@nestjs/common';
import { getSession } from 'supertokens-node/recipe/session';

export class BasicAuthGuard implements CanActivate {
  constructor() {}

  public async canActivate(context: ExecutionContext): Promise<boolean> {
    const ctx = context.switchToHttp();

    const req = ctx.getRequest();
    const resp = ctx.getResponse();

    const session = await getSession(req, resp, { checkDatabase: true, sessionRequired: true })

    req.session = session;

    if (!req.session) {
      // This should never happen, because sessionRequired is set to true above
      // which makes getSession throw if there is no active session
      return false;
    }
    return true;
  }
}

as a disclaimer: while this has been somewhat tested, it's not tested to the level we usually do it.

What this changes is that it removes the error handling part from the guard (by changing from verifySession to getSession) and rely on the exception filter handling errors. If I'm correct, this should fix your issue since it doesn't rely on

headersSent

(actually, it solves it regardless, because there is an explicit check for the session object, but that should never be hit)

If you try this, I'd be very interested if this: 1. solves your issue 2. the "this should never happen" comment holds true, as that would indicate another type of bug

(cause maybe the access token has expired)