How to set cookie domain when using Azure Front Door Manager with NextJS Static Web App

Daniel 0 Reputation points
2024-02-02T16:56:06.06+00:00

I deployed a NextJS app (that uses SSR) as a Static Web App. This works really well and is available on a domain similar to https://jolly-beach-hidden.azurestaticapps.net. I added a cookie authentication mechanism that is available at /api/auth route using NextJS app router. The client fills in the credentials and then using fetch it makes a POST request to the backend on the same domain. In the auth handler I am sending back a cookie token in the response using Set-Cookie header so that the browser persists the value and sends it on all subsequent requests. This is the cookie value:

token=${token}; Path=/; HttpOnly; SameSite=Strict; Secure; Max-Age=${maxAge};

Everything work well, both on localhost and on the azurestaticapps domain. Now, I want to support multi tenancy with my app using custom domains. So I created a Front Door and CDN profile (Standard) to define these. I successfully validated a couple of subdomains using TXT records. Also added a CNAME record to control the flow of traffic to the Front Door. Then, I added an origin group, endpoint and route pointing to the static web app, as seen below.User's image

After associating the custom domains, I can visit tenant1.custom-domain.com or tenant2.custom-domain.com and public traffic is served correctly for each tenant. Notice that the Origin host header value is the default, host name.

--

Problem

When fetching api/auth on tenant1.custom-domain.com the cookie domain gets auto set to the static web app domain. And because jolly-beach-hidden.azurestaticapps.net is different than tenant1.custom-domain.com the browser treats the cookie as invalid, as shown below: User's image

I am not able to set cookie and thus my whole multi tenant authentication isn't functional.

--

I tried setting the correct domain (tenant1.custom-domain.com) manually in the Set-Cookie header but that doesn't seem to work - the token cookie is not visible in Chrome Dev Tools. My guess is Front Door is discarding this cookie before reaching the browser.

I also tried changing the Origin host header on the origin from jolly-beach-hidden.azurestaticapps.net to tenant1.custom-domain.com but then if I visit tenant1.custom-domain.com I will get a 404 Azure error. I also tried leaving the field empty in the hope that it will be set automatically to the request host but that also causes the same 404 error.

Azure Front Door
Azure Front Door
An Azure service that provides a cloud content delivery network with threat protection.
586 questions
Azure Static Web Apps
Azure Static Web Apps
An Azure service that provides streamlined full-stack web app development.
770 questions
0 comments No comments
{count} votes

3 answers

Sort by: Most helpful
  1. ChaitanyaNaykodi-MSFT 23,106 Reputation points Microsoft Employee
    2024-02-03T02:04:32.6633333+00:00

    @Daniel

    Thank you for posting a detailed question here.

    Based on my understanding from your question above. I think you are facing the issue described in this article here.

    A host name mismatch can lead to problems when the application server issues cookies and uses the incoming host name to construct the Domain attribute of the cookie. The Domain attribute ensures that the cookie will be used only for that specific domain. These cookies can be generated by the application code or by platform features like the App Service ARR affinity setting. This diagram illustrates the problem: Diagram that illustrates an incorrect cookie domain. In order to prevent the issue above we recommend that you preserve the original host name in the call between the reverse proxy and the back-end application server: Diagram that shows a configuration in which the host name is preserved. For App Service, you can attach a custom domain name to the web app and avoid using the default azurewebsites.net host name towards the back end. You don't need to change your DNS resolution when you attach a custom domain to the web app: you can verify the domain by using a TXT record without affecting your regular CNAME or A records. (These records will still resolve to the IP address of the reverse proxy.) If you require end-to-end TLS/SSL, you can import an existing certificate from Key Vault or use an App Service Certificate for your custom domain.

    Please let us know if the proposed solution above does not work for you and we will gladly continue with our discussion.


    I hope this has been helpful! Your feedback is important so please take a moment to accept answers. If you still have questions, please let us know what is needed in the comments so the question can be answered. Thank you for helping to improve Microsoft Q&A! User's image


  2. Langatad, Sunilkumar 0 Reputation points
    2024-03-05T11:01:20.12+00:00

    Hi Danial, can you please help me understand, how were you able to use same domain name at front-door and at static web app -

    After some more research, I tried adding the tenant1.custom-domain.com as a custom domain on my Static Web App. If I do this the token cookie works as expected. However, this is not a solution for me since I want to use the Front Door manager for my tenants custom domains configuration.


  3. Langatad, Sunilkumar 0 Reputation points
    2024-03-05T13:25:26.4033333+00:00

    I found the solution. Follow the below steps -

    1. Create a file staticwebapp.config.json.
    2. Copy the below configuration into staticwebapp.config.json file, created in step 1.
       {
         "networking": {
           "allowedIpRanges": [
             "AzureFrontDoor.Backend"
           ]
         },
         "forwardingGateway": {
           "requiredHeaders": {
             "X-Azure-FDID": "<YOUR-FRONT-DOOR-ID>"
           },
           "allowedForwardedHosts": [
             "my-sitename.azurefd.net"
           ]
         }
       }
       
    

    Deploy the staticwebapp.config.json file along with application. This will restrict the application to be reached only from your front-door and keep the same domain name (as in front-door), throughout the request flow.

    References

    0 comments No comments