Getting 502 after login

[RajanPalaniya]

We are using custom domain with custom hosted page on auth0. we were earlier using the auth0-js which was completely on client side. now due to some api calls which we want to do we need session on server side, so we are migrating to this library. Now after we do login on the callback page it throws an 502 error continuously. i have checked that no extra cookies are being send nothing else is done there. our scenario is our app is hosted on another subdomain now if user hit's the request akamai will server the page from our subdomain to main domain.

I have attached screenshot of requests.

Environment

• Library version : 1.3.0
• Next JS version: 10.1.3

[adamjmcgrath]

Hi @RajanPalaniya - thanks for raising this

Not much to go on from what you've shared, but looks like an issue with your network configuration rather than the SDK. Perhaps the application running on your node server can't access the internet to do the code exchange?

[RajanPalaniya]

Hi @adamjmcgrath i guess login redirect is working properly with same configuration, it only has problem with /callback route only.

[mwisner]

@RajanPalaniya, do you, by chance, have Cloudflare or something like that setup?

We are running into the same issue. Everything works fine locally. But when the application is deployed, Cloudflare is returning a 502 for the callback URL. using some console logs. I've confirmed that the res.statusCode is being set to 302 in our custom callback handler. So I think somewhere between the custom callback code and the browser, the 302 is being changed to a 502.

[RajanPalaniya]

@mwisner We are using akamai CDN setup to drive these URLs and we're getting same error that you're facing.

[RajanPalaniya]

@adamjmcgrath i am attaching here 3 logs. if that is anything useful to you guys.

HAR : auth-callback-uat-1.har.zip ALB logs where application is hosted: ALB-AccessLog.log AKAMAI CDN server: akamai.log

[mwisner]

Still trying to debug this issue, I could be going down the wrong path here... but:

I think this is something to do with cookie size, aggregate cookie size, or aggregate header size.

https://cloud.ibm.com/docs/CDN?topic=CDN-limits-and-maximum-values#what-is-the-maximum-size-for-the-orignin-response-headers

For whatever reason, the appSession cookie is being added twice to the Set-Cookies header. so that adds a pretty big chunk of data to the headers. I'm still getting this 502 error on API calls that use getSession but was able to complete the callback login workflow by forking the repo, removing the duplicate appSession settings, and finally, by removing any extra data I can find in the actual session itself.

[mwisner]

So it turns out our Nginx ingress controller had a low default proxy_buffer, and it was sending a 502 error. And had logs that looked like this:

upstream sent too big header while reading response header from upstream

If you have a reverse proxy or something sitting in front of your node instances, I recommend reviewing the proxy size configurations. In our case, the default was the only 4k, and these session cookies used in this auth0 library are fairly large. would definitely recommend increasing them.

[RajanPalaniya]

@mwisner that is great finding. i removed id_token from session in aftercallback and it started working.

[adamjmcgrath]

Thanks @mwisner for spotting that

[michaelmcnees]

@mwisner that is great finding. i removed id_token from session in aftercallback and it started working.

@RajanPalaniya Can you provide an example of how you did this?