Hi team I m running into a new CORS error we haven t had in

Question

Hi team I m running into a new CORS error we haven t had in the past The CORS configuration is now blocking requests between our api express and client react with the error message Access to fetch at https vms api macleanengineering com auth signin from origin https vms macleanengineering com has been blocked by CORS policy No Access Control Allow Origin header is present on the requested resource If an opaque response serves your needs set the request s mode to no cors to fetch the resource with CORS disabled We ve set out cors configuration according to the user password user guide so I m starting here Here s our current cours config app use cors origin https vms macleanengineering com allowedHeaders content type supertokens getAllCORSHeaders credentials true

rp · Answer

Hi team I m running into a new CORS error we haven t had in the past The CORS configuration is now blocking requests between our api express and client react with the error message Access to fetch at https vms api macleanengineering com auth signin from origin https vms macleanengineering com has been blocked by CORS policy No Access Control Allow Origin header is present on the requested resource If an opaque response serves your needs set the request s mode to no cors to fetch the resource with CORS disabled We ve set out cors configuration according to the user password user guide so I m starting here Here s our current cours config app use cors origin https vms macleanengineering com allowedHeaders content type supertokens getAllCORSHeaders credentials true

rp · Answer

Hey

rp · Answer

Have you added the cors middleware after or before the supertokens middleware

lmac · Answer

Before it looks very similar to this snippet https github com supertokens supertokens node blob 0e3d0e30437d69edcb881c9dfb589bbea2519a48 examples express with thirdpartyemailpassword index js L120 L134

rp · Answer

Ok Can I see the response headers of the OPTIONS request that s failing

lmac · Answer

Of course interestingly the response tracking on the network shows the options as successful and then the following signin post as failing though that s not what the console error message shows

rp · Answer

So this usually happens if the cors middleware is after the supertokens middleware

rp · Answer

So it s really strange that it s happening if u have put it before the supertokens middleware

lmac · Answer

It s possible I m misinterpretting the CORS middleware before after question here is what I have

rp · Answer

Response from the sign in api is 502 That s odd We don t return the status code response from our APIs

rp · Answer

Can you enable debug logging and send the request

rp · Answer

And show the log output

lmac · Answer

It s serving from a supertokens docker container so let me also check the version tag on that

lmac · Answer

And yep I ve got it enabled let me pull the logs one moment

lmac · Answer

27 Apr 2022 13 40 20 252 +0000 | DEBUG | pid 4945ae5c 8004 4756 981e 63de68af700e | SuperTokens housekeeper thread | io supertokens storage postgresql HikariLoggingAppender doAppend HikariLoggingAppender java 136 | SuperTokens Pool stats total=10 active=0 idle=10 waiting=0 27 Apr 2022 13 40 44 666 +0000 | DEBUG | pid 4945ae5c 8004 4756 981e 63de68af700e | http nio 0 0 0 0 3567 exec 2 thread | io supertokens webserver WebserverAPI service WebserverAPI java 159 | API called hello Method GET 27 Apr 2022 13 40 44 668 +0000 | DEBUG | pid 4945ae5c 8004 4756 981e 63de68af700e | http nio 0 0 0 0 3567 exec 2 thread | io supertokens webserver WebserverAPI service WebserverAPI java 181 | API ended hello Method GET 27 Apr 2022 13 40 50 252 +0000 | DEBUG | pid 4945ae5c 8004 4756 981e 63de68af700e | SuperTokens housekeeper thread | io supertokens storage postgresql HikariLoggingAppender doAppend HikariLoggingAppender java 136 | SuperTokens Pool stats total=10 active=0 idle=10 waiting=0 27 Apr 2022 13 40 59 484 +0000 | DEBUG | pid 4945ae5c 8004 4756 981e 63de68af700e | http nio 0 0 0 0 3567 exec 3 thread | io supertokens webserver WebserverAPI service WebserverAPI java 156 | API called recipe signin Method POST Version 2 12 27 Apr 2022 13 40 59 686 +0000 | DEBUG | pid 4945ae5c 8004 4756 981e 63de68af700e | http nio 0 0 0 0 3567 exec 3 thread | io supertokens webserver WebserverAPI service WebserverAPI java 181 | API ended recipe signin Method POST 27 Apr 2022 13 40 59 690 +0000 | DEBUG | pid 4945ae5c 8004 4756 981e 63de68af700e | http nio 0 0 0 0 3567 exec 4 thread | io supertokens webserver WebserverAPI service WebserverAPI java 156 | API called recipe user Method GET Version 2 12

lmac · Answer

btw this is deployed within Kube which I have set to regularly ping the hello endpoint as a healtcheck right now while I verify this

rp · Answer

These aren t the logs I need to see

rp · Answer

There is a trouble shooting section in the docs

rp · Answer

That will show you how to enable logs from the python sdk

rp · Answer

That will help debug the issue

lmac · Answer

Sure yeah I looked at that section but wasn t sure on making those changes on the containerized deployment If I set the DEBUG field specified in the env variables will it pick it up or do I need to exec onto the instance and manually set and rerun app py

rp · Answer

I m not sure Try the env method If it doesn t work then exec into it

lmac · Answer

Env doesn t appear to have changed any terminal log output

rp · Answer

Which version of the SDK are you using

lmac · Answer

I m not sure as the image doesn t appear to have a tag designating it nor the logs anything reflecting it It s the postgres docker image found here registry supertokens io supertokens supertokens postgresql

rp · Answer

No I mean what versio of the nodejs SDK

rp · Answer

Supertokens node

rp · Answer

You need to add the debug env var whilst running your node server

rp · Answer

The supertokens node SDK will produce logs

lmac · Answer

Oh sorry still waking my brain up 8 1 2 according to my local package lock Will verify it s the same in the image as it should be this is building and serving from

rp · Answer

Right That needs to be updated to 9 1 2 at least for the debug logs to work

rp · Answer

So please do that and enable debug logs

rp · Answer

And then send them here Then we can figure what s wrong

lmac · Answer

Hi sorry for the delay in doing this I am back on it now though

lmac · Answer

Here s what my startup logs look like

lmac · Answer

I m not seeing any com supertokens logs on the api call to sign in though

rp · Answer

That means that the supertokens middleware is not being called at all Maybe something that some other middleware is throwing an error

lmac · Answer

Oh no sorry it was just not actually fetching as it had cached that resonse here are the logs I am actually seeing on hitting that endpoint

lmac · Answer

I see it says not handling because no recipe matched hmm I believe I only have the one recipe enabled right now

rp · Answer

so the middleware is not handling the request it seems

lmac · Answer

Okay so yeah that log outputs when I comment out the cors configuration on the app since you said an earlier one may be failing

lmac · Answer

and then yes it still doesn t hit the supertokens middleware when cors config is set right above it again

lmac · Answer

Welp removing and moving around where the cors middleware was assigned led to me finally realizing the issue at lesat locally about to test it on the higher envs was caused by a trailing slash on the last copy of the origin which I had taken from the error message but that trailing slash is causing the CORS failure

rp · Answer

hmmmmm

lmac · Answer

Thanks for the help setting up the debug logs

lmac · Answer

Okay I guess it was really just a getting closer

lmac · Answer

When I recreated the problem on my local I had had the slash but that didn t explain it in higher envs because my logs were showing I hadn t had the extra slash

lmac · Answer

One thing I did change that caused a difference was the SSL connection to our DB

lmac · Answer

We re connecting to an Azure managed PostgreSQL database we just switched over to that database recently so I ve been speculating it had something to do with this error but the actual CORS issue and the speculation it was a new DB related thing weren t converging Anyway the new DB requires SSL connections only so I when I accidentally removed that it helped identify the issue but now I m trying to get the supertokens core to use an ssl connection to the database and not succeeding as I try the connection string option here https node postgres com features ssl To use the Azure required usernames you have to encode as 40 but otherwise that helped resolve this for me Hope having this written out helps someone else down the line

rp · Answer

< lmac> so did you solve the issue finally

lmac · Answer

Hi yes got back to it and found the issue was caused by modifying the accesstokenpayload per this documentation https supertokens com docs emailpassword common customizations sessions new session I believe the issue seems connected to us having passed a list not str value to that field

rp · Answer

Hmm < lmac> can you show me your code related to this An object containing a key whose value is a list should work

lmac · Answer

The root cause ended up being a misuse of the accessTokenPayload vs the SessionData when overridding the createNewSession function The value being written to the accessTokenPayload exceeded the allowable buffer and therefore caused our nginx server to return a CORS issue Correcting the implementation to only store frontend needed role on the accessTokenPayload and more complex user permissions structs in the SessionData resolved this in all environments

lmac · Answer

Thanks for the help

rp · Answer

One thing to keep in mind < lmac> is that when you fetch session data it calls the supertokens core So id you need to do it in most API calls I would recommend maybe figuring out a way in which you can fit all that s required in the access token payload itself