Can't log in to admin on Chrome & Safari - possible CloudFlare cookie issue?

[gregorymark]

I've got an issue where when I try to log in to the admin section on Chrome and Safari. The authentication call goes through and it redirects to admin from the login, but then I get a 401 from the auth, store and users routes and I get redirected back to the login page. This doesn't happen on Firefox.

I don't get any useful output from Medusa when the login attempt happens, just the return of the 401. In Chrome's response headers for set-cookie, there's a warning and it says

This Set-Cookie didn't specify a "SameSite" attribute and was default to "SameSite=Lax" and was blocked because it came from a cross-site response which was not the response to a top-level navigation. The Set-Cookie had to have been set with "SameSite=None" to enable cross-site usage.

My NODE_ENV=production so it should be being set to none, but that isn't happening (both Secure and SameSite have no value). I can manually set Secure and SameSite and this then allows login, but it causes other issues from my storefront. Plus it's not a very satisfying conclusion.

I'm running medusa at a subdomain through CloudFlare using a proxied A record, so this stackoverflow issue seems to be close to my problem, but the only solution there is already how things are set up here i.e. we're using app.set("trust proxy", 1). The admin is on Netlify at a netlify.app domain.

Also I'm not sure if this should actually be a medusajs/medusa issue, rather than admin as it seems that my problem is with the cookie that's being set there, but it's presenting as an admin issue so I'm posting here for now.

[edihasaj]

Is there any solution to this?

[olivermrbl]

Posting a response from @adrien2p on this issue after he had been running with different server configurations:

here are my trials to help you find out your issue on the cookies
- `NODE_ENV=dev` with http server -> works
- `NODE_ENV=production` with http server -> fails
- `NODE_ENV=production` with local https server and locally generated certificate -> works

cookies do not show on the browser but still work -> domain cannot be set on the cookie via the configurations, therefore the domain used by default is the origin server which means it is not shown in the browser https://stackoverflow.com/questions/43324480/how-does-a-browser-handle-cookie-with-no-path-and-no-domain

About the cookies that does not appears in your browser
https://stackoverflow.com/questions/43324480/how-does-a-browser-handle-cookie-with-no-path-and-no-domain

also, a secure cookie can't be attached on an http request

This might not resolve your issue, but thought I'd post it as it sheds some light on what could be the culprit.

In the meantime, we'll investigate it further.

[edihasaj]

Thanks for your reply Oliver, I think since we don't have a stable solution yet, we will seek to fix the problem, or wait for additional information about the problem.

For me only works with firefox and production with Static IP and no secure https connection (though haven't tried with https in production).

[gregorymark]

@olivermrbl yeah, thanks for the response (and Adrien). I'll look into my CloudFlare setup and try and get it working but for now I don't have much time so I'll just be using Firefox until I can investigate properly.

[dan5082]

I am not using cloud flare but have the same issue. Firefox works

[adrien2p]

Here is a complementary information to my previous research

netlify app is part of the Public Suffix List https://publicsuffix.org/list/public_suffix_list.dat
Which means that we have a problem at the moment which is the following,

When deploying your application in production/staging env, the cookie is set to secure and SameSite=None

What's happening is that on those domains (see the list above) the sub domains are considered as cross site access, basically you can see it like you can't have access to a sub domain from netlify since it can belongs or not belongs to you, so the browsers chose to handle it that way. If it is part of that list, all sub domain are considered as cross site.

Another example to see it, when deploying on github.io, you can have your.github.io and me.github.io and both are sub domains of github.io and can't access each others. So, github.io is also part of the list above. That is in that sense that they are considered cross site access for that list

btw, heroku is also part of that list

[edihasaj]

Deploying to self-managed server is giving the same result. Though there should be a way to allow cross-site from medusa.

[revskill10]

So, basically this repository is unsuable within cloud environment ?

[SaadBazaz]

Same issue! Instant login / logout. I suspect it's due to cookies too.

My environment:
Backend deployed on a self-hosted cloud. (CapRover with custom domain)
Admin panel deployed on Vercel. (.vercel.app)
Storefront deployed on Vercel. (.vercel.app)

[edihasaj]

@SaadBazaz node environment should be on production, jwt_secret should be set, and of course to not forget to add the domain in CORS. This worked for me

[SaadBazaz]

@SaadBazaz node environment should be on production, jwt_secret should be set, and of course to not forget to add the domain in CORS. This worked for me

Node environment and JWT on which project? Backend or Admin Panel?

[edihasaj]

Api backend

[SaadBazaz]

node environment should be on production, jwt_secret should be set, and of course to not forget to add the domain in CORS

Worked perfectly for me. Now localhost:7000 and cloud deployment (Vercel) are working. Thanks!