Hello,
I am experiencing issues with the session cookie not being set in Safari and Chrome incognito.
Updated:
Safari (doesn't work for both localhost and heroku)
Chrome (doesn't work for heroku)
Firefox (doesn't work for heroku)
I have a "customer" collection that needs to be able to log in on the website, and for that collection I have the auth set to:
auth: {
tokenExpiration: 43200,
maxLoginAttempts: 15,
lockTime: 60000,
cookies: {
secure: true,
sameSite: 'none'
},
}
Taking Safari as an example, I am getting the token in the response:
And the user is logged in, but the cookie is not set. So once I refresh the page, the user is again not logged in.
Would greatly appreciate any ideas on how to fix this.
Thank you, Merry Christmas and happy holidays :)
Hey @vstarush —
What domain(s) are you using for your Payload API and your frontend website API?
It looks like you are specifying Secure
on your cookie, but using an insecure domain (http://localhost:3000
). This may cause the cookie rejection.
Also, another thing to check into would be how browsers have started to handle third-party cookies. By default, third-party cookies are now rejected across the board - which means that if you have your API and your website running on separate domains, you won't be able to use the cookie as you're intending to. I'm not yet sure that this is the issue you're experiencing though.
First, I'd check the Secure
setting. Maybe only enable Secure
in production environments or deployments where you can ensure HTTPS on both your API and your site.
Let me know what URLs you're using for your Payload API and your frontend site and we can go from there!
Thank you @jmikrut ! Placing the frontend and backend under same domain worked like a charm.
Hey @vstarush, could you please elaborate how did you resolve this? I'm currently facing this issue too.
Hey @vstarush —
What domain(s) are you using for your Payload API and your frontend website API?
It looks like you are specifying
Secure
on your cookie, but using an insecure domain (http://localhost:3000
). This may cause the cookie rejection.Also, another thing to check into would be how browsers have started to handle third-party cookies. By default, third-party cookies are now rejected across the board - which means that if you have your API and your website running on separate domains, you won't be able to use the cookie as you're intending to. I'm not yet sure that this is the issue you're experiencing though.
First, I'd check the
Secure
setting. Maybe only enableSecure
in production environments or deployments where you can ensure HTTPS on both your API and your site.Let me know what URLs you're using for your Payload API and your frontend site and we can go from there!
Hey @jmikrut, I'm facing this issue too. Cookies are not being set at my end too. I'm running the frontend server on http://localhost:3000
and the backend is hosted on AWS for testing purposes. What should I do so to resolve this?
What solved the problem for me is putting the front end and backend under same domain. For example:
Frontend: https://domain.com
Backend: https://backend.domain.com
The problem is, as @jmikrut mentioned, with the third-party cookies, browsers now do not allow to set them from a different domain. But if the frontend and backend is under one domain, all works fine.
How do I make it work, if I don't have a subdomain? And how did you test it locally before going in production?
Things are changing so quickly in regards to third-party cookies that I would probably stand up a staging backend AND a staging frontend, each with subdomains on the same domain, to determine with certainty that your cookies will be considered first-party and therefore work.
One other note, I'm not sure off the top of my head. But if you are using 2 subdomains, you may need to set the cookieDomain
option of your auth config to be equal to the root domain (NOT a subdomain). If you put a dot before the domain, that will signify that it can be used across all subdomains.
Example cookie domain: .website.com
. This would then work for frontend.website.com
AND .backend.website.com
.
Thanks @jmikrut for a precise and quick reply. I guess that makes up for the question. I'd try and see if that works. Thanks, again!
Star
Discord
online
Get dedicated engineering support directly from the Payload team.