https://supertokens.com/ logo
Title
m

mjmon-upwego

02/11/2023, 11:45 AM
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?
r

rp

02/11/2023, 12:14 PM
hey @mjmon-upwego
> 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 How did you check this? Can you print out the request headers right before calling verifySession / getSession function from supertokens?
m

mjmon-upwego

02/11/2023, 3:35 PM
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'
}
r

rp

02/11/2023, 3:36 PM
hmm. So the cookies are there.
Which framework are you using supertokens with?
m

m-j-mon

02/11/2023, 3:57 PM
Supertokens-node
r

rp

02/11/2023, 3:57 PM
And which node framework? Express?
Can you also share code of how you are using our verify session functions?
m

m-j-mon

02/11/2023, 4:14 PM
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.
r

rp

02/11/2023, 4:15 PM
Hmm this is really strange
VerifySession uses getSession
Oh right I see the issue
Hmm actually
This seems fine
m

m-j-mon

02/11/2023, 4:17 PM
Ha. I was full of hope 😁
I’m away from my dev machine at the moment, but next step was to print the headers from within the routes that are working to do a comparison. Once I’ve done that I’ll post here.
r

rp

02/11/2023, 4:18 PM
Yea. That would be helpful. Maybe print the req object right before calling getSession
m

m-j-mon

02/11/2023, 4:19 PM
Will do.
m

mjmon-upwego

02/11/2023, 6:21 PM
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?
Working on getting the req logged and compared - bit more to it 🙂
r

rp

02/11/2023, 6:23 PM
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
@m-j-mon I’m also happy to jump on a call sometime in the coming week to help debug. This is an interesting issue
If you are open to this, you can pick a time you like in supertokens.com/call-user
m

mjmon-upwego

02/11/2023, 6:49 PM
Awesome. That'll be great. I'll get something booked in.
r

rp

02/11/2023, 6:49 PM
Cool
To make the call most productive, you could try and isolate this issue in a mini demo app. And be sure to use our latest SDK versions
If this works on our latest SDK versions, and not the version that you are currently using, then we may just be able to figure it out without a call
m

m-j-mon

02/11/2023, 6:58 PM
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.
r

rp

02/11/2023, 6:58 PM
You don’t need to use headers. Just upgrade the SDKs on the frontend and backend and continue to use cookies
There should be no / minimal code change required
m

m-j-mon

02/11/2023, 7:00 PM
👍🏼
m

mjmon-upwego

02/12/2023, 12:07 AM
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.
r

rp

02/12/2023, 4:08 AM
Ok awesome!!