Hey all. This is a reach-out for help before I grab a flask of coffee, put the pods in, and get into the zone of debugging 🙂 I've successfully set up SuperTokens (ST) using reactjs for the UI and nodejs for the backend, which is sitting behind a Traefik gateway. All is working as expected in this simple setup. However, I'd like to use the forwardAuth middleware in Traefik to validate the ST session, obtain metadata, and forward the request to other services with additional header data. I've checked the request from the forwardAuth in the AuthApi, and it looks correct, e.g. the cookies are present etc., but attempting to get the session throws the following error:

SessionError: Session does not exist. Are you sending the session tokens in the request as cookies?
    at Object.<anonymous> (/Volumes/Development/a4t/a4t-auth-api/node_modules/supertokens-node/lib/build/recipe/session/recipeImplementation.js:159:27)
    at Generator.next (<anonymous>)
    at /Volumes/Development/a4t/a4t-auth-api/node_modules/supertokens-node/lib/build/recipe/session/recipeImplementation.js:30:75
    at new Promise (<anonymous>)
    at __awaiter (/Volumes/Development/a4t/a4t-auth-api/node_modules/supertokens-node/lib/build/recipe/session/recipeImplementation.js:12:16)
    at Object.getSession (/Volumes/Development/a4t/a4t-auth-api/node_modules/supertokens-node/lib/build/recipe/session/recipeImplementation.js:139:20)
    at Object.<anonymous> (/Volumes/Development/a4t/a4t-auth-api/node_modules/supertokens-node/lib/build/recipe/session/index.js:156:55)
    at Generator.next (<anonymous>)
    at /Volumes/Development/a4t/a4t-auth-api/node_modules/supertokens-node/lib/build/recipe/session/index.js:44:75
    at new Promise (<anonymous>) {
  type: 'UNAUTHORISED',
  payload: { clearCookies: false },
  errMagic: 'ndskajfasndlfkj435234krjdsa',
  fromRecipe: 'session'
}

Has anyone managed to get a setup similar to this working, and if so, could you give some pointers?

hey @mjmon-upwego

Hey @rp , thanks for the quick response. As requested:

verify headers {
  host: 'docker.for.mac.localhost:4000',
  'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36',
  accept: '*/*',
  'accept-encoding': 'gzip, deflate, br',
  'accept-language': 'en-US,en;q=0.9',
  'cache-control': 'max-age=0',
  'content-type': 'application/json',
  cookie: 'sIdRefreshToken=7b99718d-9393-491c-947f-0c1d47d5614c; sAccessToken=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsInZlcnNpb24iOiIyIn0%3D.eyJzZXNzaW9uSGFuZGxlIjoiZjgzNmM2NWYtMTNmMS00ODdmLTlkMzItNjU2NjUyOGUxZjc2IiwidXNlcklkIjoiYTY1MzFkZWUtMzc5Mi00OWMwLTg3N2ItOWNhMGRkYTI4MDBjIiwicmVmcmVzaFRva2VuSGFzaDEiOiIxOWQxM2VjZDUzZjk3NGI1MTEzYzI5ZWM0MTVkMTkzOWE0NDA4YTAwZDgwODg4MDkyNTBiZjFjYjQxZWNjNDZkIiwicGFyZW50UmVmcmVzaFRva2VuSGFzaDEiOm51bGwsInVzZXJEYXRhIjp7fSwiYW50aUNzcmZUb2tlbiI6bnVsbCwiZXhwaXJ5VGltZSI6MTY3NjEzMjg4MzM5MCwidGltZUNyZWF0ZWQiOjE2NzYxMjkyODMzOTAsImxtcnQiOjE2NzYxMjkyODMyOTB9.b9bHQi3FhyTj84kwaEgts65xeYxvFH6osLg91g6J6txcIHjZNYlJr9P1QS9RzOxAz4JNfyqnbjKvaQC%2Fr%2BhLX7BHs7G0OanOszKpSSFIlZgeuqE44sM1pLFWb7mnouI%2BiJeDLDpAm8YNrg4VsA9y%2F77wgV%2BTvdvs7AKIfmLUMZvGNqtFqVDpBa5LDEr6lQVsFtnFl2%2FLEYiUbYt7jjiFsmXnm%2Bz9uyI43Caa3oTSoWb%2F3aEensxOWCydsNfQgXkDjTEwPeFAGt7brr6YZCyvZ0i4ooqEP8xiWvejL1dt9k5%2BVx61ya35z%2BmYPT2VZ4jJX8iyu4ACQmxSNpBN1BfpeQ%3D%3D',
  dnt: '1',
  origin: 'http://a4tlocalapp.docker.localhost',
  rid: 'anti-csrf',
  'sec-ch-ua': '"Chromium";v="109", "Not_A Brand";v="99"',
  'sec-ch-ua-mobile': '?0',
  'sec-ch-ua-platform': '"macOS"',
  'sec-fetch-dest': 'empty',
  'sec-fetch-mode': 'cors',
  'sec-fetch-site': 'same-site',
  'x-forwarded-for': '172.30.0.1',
  'x-forwarded-host': 'a4tlocalapi.docker.localhost',
  'x-forwarded-method': 'GET',
  'x-forwarded-port': '80',
  'x-forwarded-proto': 'http',
  'x-forwarded-server': '9c3a23d44a18',
  'x-forwarded-uri': '/api/calendars',
  'x-real-ip': '172.30.0.1'
}

hmm. So the cookies are there.

Supertokens-node

And which node framework? Express?

Yeah, express.

const express = require('express');
const supertokens = require('supertokens-node');
const SessionNode = require('supertokens-node/recipe/session');
…

app.get('/verify', async (req, res) => {
   console.log(‘verify headers’, req.headers);
const session = await SessionNode.getSession(req, res);
   res.status(200).send('OK');
}

Keeping it simple, so just trying to get the session at the moment. The exception is thrown at the getSession. Other routes like the one below are working fine:

app.get('/auth/user-profile', verifySession(), async (req, res) => {
  const session = req.session;
  const userId = session.getUserId();

  let userInfo = await EmailPasswordNode.getUserById(userId);
  if (userInfo === undefined) {
    res.status(401).send('Unauthorized');
    return;
  }
  const { metadata } = await UserMetadata.getUserMetadata(userId);

  const profileData = {
    firstName: metadata.firstName,
    lastName: metadata.lastName,
    email: userInfo.email,
  };

  res.json({ profile: profileData });
  return;
});

I’ve purposely not used the verifySession() in the /verify route so I could do debugging, eg show the headers. The aim will be to introduce that back in once this is figured out.

Hmm this is really strange

Ha. I was full of hope 😁

Yea. That would be helpful. Maybe print the req object right before calling getSession

Will do.

Here's the comparison of the headers. One of the left (user profile) works, but the one on the right (verify) doesn't. Differences seem to be: - User profile doesn't have cache-control - User profile doesn't have content-type - User profile doesn't have x-forwarded-method - User profile doesn't have x-forwarded-uri None of those IMO would cause the issue. - Verify doesn't have 'if-none-match' - Verify doesn't have referer - The host is also different. Would any of those cause the getSession to fail?

The in my thing that would result in this kind of an error is if the cookies are not present in the request object. But they seem to be.. so very strange

Awesome. That'll be great. I'll get something booked in.

Cool

That’s a good point. I’m on 12.1. I’ll upgrade to 13.0 and give it a go as I can see there’s quite a bit of work to use headers as an option.

You don’t need to use headers. Just upgrade the SDKs on the frontend and backend and continue to use cookies

👍🏼

Hey @rp , Good news. Upgrading to the latest version, and it works. Did a bit of digging and with supertokens-auth-react 0.31.0 and supertokens-web-js 0.5.0 versions my endpoint gets two requests, one for OPTIONS and one for GET.

verify headers {
  host: 'docker.for.mac.localhost:4000',
  'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36',
  accept: '*/*',
  'accept-encoding': 'gzip, deflate, br',
  'accept-language': 'en-US,en;q=0.9',
  'access-control-request-headers': 'content-type,rid,st-auth-mode',
  'access-control-request-method': 'GET',
  'cache-control': 'max-age=0',
  origin: 'http://a4tlocalapp.docker.localhost',
  'sec-fetch-dest': 'empty',
  'sec-fetch-mode': 'cors',
  'sec-fetch-site': 'same-site',
  'x-forwarded-for': '172.30.0.1',
  'x-forwarded-host': 'a4tlocalapi.docker.localhost',
  'x-forwarded-method': 'OPTIONS',
  'x-forwarded-port': '80',
  'x-forwarded-proto': 'http',
  'x-forwarded-server': '9c3a23d44a18',
  'x-forwarded-uri': '/api/calendars',
  'x-real-ip': '172.30.0.1'
}

The OPTIONS doesn't have the cookie and therefore failed to get a session (obviously). So, I can now take the appropriate action and only get the session for the actual GET request. I've added a lot of debug and might have accidentally changed other logic, so I'm going to spend a bit of time tomorrow reverting the changes to ensure this is definitely a version upgrade fix.

Ok awesome!!