it sets the cookie if I run the server locally, but when it is hosted online :
then I tried with secure=true
Why is this happening?
Hello @prashanshan6 did you have a look (search) for similar issues that are closed.
Are you using a proxy?
I will get to this question but am addressing another issue today.
@ghinks Hello, I'm sorry.
I've found the issue.
The browser is indeed setting the cookie.
I've hosted the backend in Heroku lets say at the domain xyz.com
and I've hosted my frontend at another domain lets say aaa.com.
I was trying to set the cookie to the domain aaa.com(front-end),
but _since the response is coming from xyz.com the cookies are set to xyz.com domain_
I did some research online and found that sessions are not used in REST APIs often because it isn't stateless,
So I switched to using JWT Tokens.
But I am just curious shouldn't the cookies be stored in the domain of the Client rather than the domain of the Server?
Please correct me if I am wrong.
I read the documentation and tried to change the domain by setting the domain field, It changed the domain value in the received cookie but it didn't set the cookie, What am I doing wrong here?
But I am just curious shouldn't the cookies be stored in the domain of the Client rather than the domain of the Server?
This is a question to your web browser, not this module :) This module is not causing them to be store in a particular place, as it is the web browser making such a decision.
I read the documentation and tried to change the domain by setting the domain field, It changed the domain value in the received cookie but it didn't set the cookie, What am I doing wrong here?
You should see that value in the response set-cookie header. But it is up to your web browser to honor the setting. Perhaps it is a bug in the web browser, not sure. Best to bring it up with the web browser vendor.
@dougwilson I tried it in different browsers and in Postman it didn't set the cookie when the domain field was changed.
Ok. So is this module doing something wrong / what is the fix? You're welcome to open a pull request, but as far as I'm aware, there is nothing this module can do to get the browsers to store the cookie in your scenario. But if you can show otherwise what can be changed, we're happy to reopen. But keeping the issue open won't make a fix happen if we have no idea how to fix it :)
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie
A cookie for a domain that does not include the server that set it should be rejected by the user agent.
Yes now I understand its a browser issue, but I have a doubt
If the cookie won't be accepted by the browser when the domain field is set to domains other than the server, Then what purpose does the domain field serve in session config?
If the cookie won't be accepted by the browser when the domain field is set to domains other than the server, Then in what purpose does the domain field serve?
Certainly, a question again to ask the web browser vendors :) They accept it being there, so we provide the ability to specify it in this module. What the web browser decide they are going to accept as the value is ultimately up to them to explain.
It can be a subdomain, or a higher level domain
Apparently there are some incompatible clients like ios 12 webview. Could we add support for this? I know it's hackish but it would break cookies for too many people.
https://www.chromium.org/updates/same-site/incompatible-clients
Add the middleware from https://www.npmjs.com/package/should-send-same-site-none to your Express app and it will address thus for all other middleware (like this one) that need to set cookies with sameSite=None
It will sniff the user agent and remove the samesite when necessary.
Brilliant! Thanks @dougwilson