Received cookies are always stored under the front-end domain name in browser cookie storage. In case when server domain differs and cookies are saved successfully, the effect is the same as if they have been sent by the front-end domain in the first place.
if SameSite=None cookie attribute is omitted today’s browser (Firefox/Chrome) will use default Lax mode which is too strict for cross site cookies
if Secured cookie attribute is omitted - then SameSite=None will be ignored - it requires Secured to be set.
To answer your first point the main issue is that the received cookies aren’t stored under the front-end’s domain name.
For example, I’m using firebase hosting, so my domain name is “web.app”. So I explicitly defined that domain name:
hey raouf, what was the fix specifically? I lm getting same domain invalid warning in browser eventhough cookie domain is set to same as my front end domain.
You just omit specifically setting the domain? That works and the cookie gets set for me, as well, but the cookie gets set as domain: proj.web.app and I need the cookie to be set for all domains of web.app not just sub-domains of proj.web.app.
For anyone that is running into this issue I believe I have found the cause of the problem that is making the browser reject setting the cookie and a possible solution.
The cause: The domains .web.app and .run.app are on a list called the public suffix list and is considered to broad a domain so the browser rejects setting the cookie.
The solution: Use custom domains with your Firebase app then use Firebase Hosting rewrites that will allow you to make API calls through your custom domain and routes them to the correct Cloud Function.