Session cookie not created when static web app is sitting behind azure front door due to domain mismatch

[jaandrews]

Session cookie not created when static web app is sitting behind azure front door due to domain mismatch

[vvo]

the domain iron-session attaches to the cookie
I don't think our code tries to do anything smart with the domain option of the cookie. We use the browser defaults here.
So probably by default, it will try to use the request domain?

I am unsure to understand the exact issue, perhaps you can dig it more and show a few examples of when is the domain an issue? (I don't know Azure much)

[jaandrews]

Say I have a website with the url example-a.com sitting behind a front door instance with url example-b.com. The user navigates to example-b.com to access the site, but because the site is actually running on example-a.com, iron-session sets example-a.com as the domain when it creates the cookie and so the browser blocks that because it's trying to add that cookie to example-b.com.

While it's not the way I'm using it, front door can also be used as a load balancer, which would run into similar issues and I imagine similar issues would happen with non azure load balancers. Not sure there is anything that can be done on your side, so feel free to close this if that's the case.

[jaandrews]

For anyone else running into this problem, I did get a recommendation from azure support on how to tackle this issue. Basically it involves forcing all of the environments to use the same url. Their solution can be seen below.

My suggestion to correct the issue is to configure a custom domain in Front Door and create the same custom domain in the static web app. Then configure the Origin so that the host header parameter is empty, that way the host header passed to the Static Web App will be the same as your custom domain, the expectation is that cookies are created for that domain and won't cause any mismatch issues.