https://supertokens.com/ logo
Cors errors
c

cbwhite920

03/20/2023, 9:21 PM
How do I resolve 204 responses from my auth endpoints for the OPTIONS calls? They’re causing CORS errors but I’ve ensured my CORS setup is right, allowing the right origin, methods, headers, etc.
n

nkshah2

03/21/2023, 3:58 AM
Hi @cbwhite920, Can you post the error you see in the browser console for the CORS error? Along with the cors and SuperTokens init setup in your backend
c

cbwhite920

03/21/2023, 5:12 PM
absolutely, grabbing those now
here's the error in browser console
CORS setup in my Http Api Gateway
SuperTokens init setup in backend
export const getBackendConfig = () => {
  return {
    framework, // awsLambda
    supertokens: {
      connectionURI: supertokensUri,
      apiKey: supertokensApiKey,
    },
    appInfo: {
      appName,
      apiDomain, // https://rfid1dfw6i.execute-api.us-east-1.amazonaws.com
      websiteDomain, // https://d1l44yiy5f0ck4.cloudfront.net
      apiBasePath: '/auth',
    },
    recipeList: [
      Dashboard.init({
        apiKey: supertokensApiKey,
      }),
      ThirdParty.init({
        signInAndUpFeature: {
          providers: [
            {
              id: 'O365',
              get: (redirectURI, authCodeFromRequest) => {...} // extracted for character limit
            },
          ],
        },
      }),
      Session.init({
        jwt: {
          enable: true,
        },
        // TODO conditionally set this, might have prod with same domain base
        // between website domain and api domain
        getTokenTransferMethod: () => 'header',
        cookieDomain: '.amazonaws.com',
        override: {
          functions: function (originalImplementation) {
            return {
              ...originalImplementation,
              createNewSession: async function (input) {
                input.accessTokenPayload = {
                  ...input.accessTokenPayload,
                  aud: azureAdClientId, // client id registered in Azure AD
                }

                return originalImplementation.createNewSession(input)
              },
            }
          },
        },
      }),
    ],
    isInServerlessEnv: true,
  }
}
also, here is my handler for the auth endpoints lambda:
exports.handler = middy(middleware())
  .use(
    cors({
      origin: getBackendConfig().appInfo.websiteDomain,
      credentials: true,
      headers: ['Content-Type', ...supertokens.getAllCORSHeaders()].join(', '),
      methods: 'OPTIONS,POST,GET,PUT,DELETE',
    })
  )
  .onError((request) => {
    console.log(JSON.stringify(request))
    throw request.error
  })
ok @nkshah2 i found some information saying that in AWS if you apply CORS settings at the Api Gateway level for http api, it overrides. the headers and our supertokens headers are lost. the recommendation is to not set CORS settings on the gateway, and then just handle setting CORS headers directly in your lambda and explicitly set up an OPTIONS handler for that. That got me past that 204 issue on the OPTIONS call. Now I'm able to get the third party authorization url, redirect to the id provider, authenticate successfully, then get redirected to my callback. BUT, it's still not able to find an active session even after that, and it keeps calling /auth/session/refresh which is giving me a 401 unauthorized... Is this a common issue when hosting a frontend in Cloudfront via an S3 bucket static spa app?
I have it configured to use header based auth since my frontend and backend are on different domains, but the Authorization header doesn’t seem to be getting passed in for the session refresh call or hitting my api
n

nkshah2

03/22/2023, 5:01 AM
Hmm im not super familiar with AWS, perhaps @rp can help better here
r

rp

03/22/2023, 5:32 AM
hey @cbwhite920
whats the request header as seen on the chrome's network tab when the refresh API is called?
so this doesn't have the authorization bearer token in it. What are the cookies stored on the frontend before this call is made?
c

cbwhite920

03/22/2023, 11:26 AM
Correct, I’m seeing that there aren’t any cookies stored
r

rp

03/22/2023, 11:41 AM
right. Can i see the request and response headers for the sign in API call?
c

cbwhite920

03/22/2023, 11:51 AM
Absolutely grabbing it now
r

rp

03/22/2023, 11:55 AM
right, and if this returns successfully, do you see st-access-token in cookie store along with st-refresh-token?
c

cbwhite920

03/22/2023, 11:55 AM
in the allow headers on the request i added Authorization to see if it would help bring over the Authorization header but it didnt seem to help
I’m still not seeing any cookies for the site
r

rp

03/22/2023, 11:59 AM
That’s really strange. Hmmm
Perhaps @porcellus can help here
p

porcellus

03/22/2023, 12:06 PM
hi
this is really strange 🙂
could you enable debug logs on the frontend (
enableDebugLogs: true,
in ST init), go through the login again and post the logs?
there'll be a ton of logs, so I'd prefer it in text form (you can right click the debugger console and save the entire thing into a file I think)
c

cbwhite920

03/22/2023, 12:12 PM
Ah nice, yes will be able to try that out and send over in about a half hour
p

porcellus

03/22/2023, 12:12 PM
thanks 🙂
c

cbwhite920

03/22/2023, 1:24 PM
sorry for the delay
attaching now
p

porcellus

03/22/2023, 1:41 PM
it looks like for some reason no cookie is saved
when you open the site is there an
st-last-access-token-update
cookie?
did you maybe open the site in incognito?
r

rp

03/22/2023, 1:43 PM
even with incognito, it should have worked - cause these cookies are attached to the website domain and not api domain
p

porcellus

03/22/2023, 1:43 PM
right, could you show the FE config as well?
c

cbwhite920

03/22/2023, 1:58 PM
absolutely, here's my frontend config
SuperTokens.init({
  appInfo: {
    appName: 'Time and Billing Supertokens POC',
    apiDomain: 'https://rfid1dfw6i.execute-api.us-east-1.amazonaws.com',
    apiBasePath: '/auth'
  },
  recipeList: [
    Session.init({
      tokenTransferMethod: 'header',
      sessionTokenFrontendDomain: '.cloudfront.net',
      sessionTokenBackendDomain: '.amazonaws.com'
    }),
    ThirdParty.init()
  ],
  enableDebugLogs: true
});
if it was an issue with the frontend being hosted in an S3 bucket exposed via Cloudfront that's causing the Authorization header not to be sent, would we still see the debug logs trying to send that header?
p

porcellus

03/22/2023, 2:11 PM
This seems fairly insecure - basically, the tokens are accessible (or would be if they were saved) by '*.cloud front.net' and sent with requests to '*.Amazon and.com'
r

rp

03/22/2023, 2:13 PM
Ah right. So the .cloudfront.net is a public suffix domain and browsers won’t accept cookies for that (which is what we are seeing)
p

porcellus

03/22/2023, 2:13 PM
I'm on mobile right now (just left a few mins before your message) so I'll look into it a bit more, but could you try removing the frontend domain from the config?
c

cbwhite920

03/22/2023, 2:14 PM
no problem, just pushed that change so will check it once live
I didn't want to buy domains for this since this is just a proof of concept I'm trying to stand up in a sandbox environment in order to propose this to my team as a better option than the current Cognito setup we have
so if I can get this working and the team likes it we'd integrate it with our own domain and I think we have VPC's and such as well
r

rp

03/22/2023, 2:16 PM
Right now, you can remove the sessionTokenFrontendDomain and it should work. Try that
c

cbwhite920

03/22/2023, 2:21 PM
wonderful, ok that made it work the cookies are being saved and when I refresh the page after successful login, st is able to find the alive session
if we eventually integrate this and migrate to our own domains, would I need to add that back into the frontend config?
r

rp

03/22/2023, 2:27 PM
you would want to add this to the frontend config only if you want to share sessions across sub domains, else not
c

cbwhite920

03/22/2023, 2:29 PM
ok makes sense thank you! I really appreciate the help from both of you!!
I'm still getting cors errors from frontend to my api, but it looks similar to what I've resolved with getting my /auth endpoints to work so I'm hoping I can work that piece out
have you seen issues with using jwt authorizers in AWS?
I've got my api using jwt authorizers and am getting this error
when I check out the token, I see that it's a SuperTokens token that includes jwt in it, and then when I check out the contained jwt, that one has the kid value that the jwt authorizer is looking for. Do you know how I can get that fixed?
r

rp

03/22/2023, 8:00 PM
You should extract the JWT from on the frontend and send that as the authorization header in the request. See the section in our docs about using with JWT.
c

cbwhite920

03/22/2023, 8:26 PM
ah ok cool thank you
ok, that resolved jwt authorizer issue but I still just can't seem to get a successful response from my api. Have worked through so many issues hopefully this is the last one, and it seems like this might be AWS specific. the lambda at my api endpoint is getting hit and returning the data I'm expecting, but for some reason at the API Gateway level it's giving me an error 500 and not sending back my results to the frontend. any idea on this one?
r

rp

03/23/2023, 1:59 AM
Any error logs?
c

cbwhite920

03/23/2023, 11:06 AM
Unfortunately not, the logs in the gateway just show normal activity and then the response shows that the integrated lambda returns a successful response but the gateway is sending back internal server error with no further info
And it’s an Http Api Gateway which apparently provides fewer logs than a Rest Api but I was struggling to get the Rest Api to work before
r

rp

03/23/2023, 11:10 AM
hmm. Thats odd
is the response 500? Or 502?
cause a 502 usually means that the response header length is too long and that can be fixed with some config on the gateway
c

cbwhite920

03/23/2023, 12:54 PM
Ah ok that’s good to know. In this case it’s 500 coming back
I might have to try switching back to a Rest Api at some point and give that another shot. I was having issues getting the lambda authorizer to work which is why I switched to Http but thinking I can hopefully have a better chance with that option
Apparently the Rest api supports more logging capabilities that would help troubleshoot the lambda 200 —> gateway 500 issue
r

rp

03/23/2023, 1:07 PM
right. Im not an expert at aws either unfortunately. Might be better off asking aws support, or see if you can fish something from our docs
c

cbwhite920

03/23/2023, 2:19 PM
Yeah no worries, might have to do that, I appreciate you helping think through it. I’m hoping with the additional logging available with Rest api gateways I’ll have enough info to work it out, and maybe going that route I won’t even see that specific issue