x-ms-client-principal header not included when request rewritten to API via navigationFallback

[geoffrich]

Describe the bug

The x-ms-client-principal header is not consistently sent to the Static Web App's API function. In particular, when the request is rewritten to the API route via navigationFallback and the route does not have an allowedRoles, the header is not present.

If the route does have an allowedRoles or if the route is rewritten to the API route outside of navigationFallback, then the header is present.

To Reproduce

live demo

demo repo

Given a Static Web App with an Azure Function API available at /api/auth-test, an index.html file, and the following config:

{
  "routes": [
    {
      "route": "/api-rewrite",
      "rewrite": "/api/auth-test"
    },
    {
      "route": "/protected",
      "allowedRoles": ["authenticated"]
    }
  ],
  "navigationFallback": {
    "rewrite": "/api/auth-test"
  }
}

1. Login (e.g. via /.auth/login/github)
2. Navigating to /api/auth-test (the API function), /api-rewrite (which rewrites the request via routes), and /protected (which rewrites the request via navigationFallback and has an allowedRoles) all correctly rewrite the request to the API function at /api/auth-test and include the x-ms-client-principal header
3. Navigating to /whatever (which rewrites the request to the API function via navigationFallback and does not have an allowedRoles) does not include the x-ms-client-principal header

You can clearly see this on my demo site linked above. The API function returns the x-ms-client-principal headers it receives.

Expected behavior
The x-ms-client-principal header is provided for all requests to the API.

Screenshots
n/a

Device info (if applicable):
n/a

Additional context
I maintain the SvelteKit integration for Azure Static Web Apps, svelte-adapter-azure-swa. This issue is preventing SvelteKit users from getting consistent access to authentication info via the x-ms-client-principal header.

The adapter works by rewriting requests in navigationFallback to an Azure function that runs the SvelteKit request handler to server-side render the page, among other things. If the requested route is not present in the SWA route config with an allowedRoles specified, then the request does not have access to authentication info via the header.

[thomasgauvin]

Hey @geoffrich! Thanks for the feedback and the great work on svelte-adapter-azure-swa. We'll look into this

[geoffrich]

Thanks! It's worth noting that the issue I report here only happens on the deployed site - when running the demo locally with the SWA CLI, I get the header back in all cases.

[derkoe]

Just ran into the same issue - here is a demo repository to reproduce this: https://github.com/derkoe/azure-swa-auth-issue-with-nav-fallback (here is the deployed version https://proud-moss-0ed9eb403-test.westeurope.1.azurestaticapps.net/)

[derkoe]

There is a workaround for this:

• adding an "allowedRoles" with route "*"
• adding all non-secured routes (a long list) in front of it

Here is an example for this:

{
  "navigationFallback": {
    "rewrite": "/api/render"
  },
  "routes": [
    {
      "route": "/manifest.json"
    },
    {
      "route": "/service-worker.js"
    },
    {
      "route": "/robots.txt"
    },
    {
      "route": "/static/*"
    },
    ...
    {
      "route": "*",
      "allowedRoles": ["authenticated"]
    }
  ]
}

[thomasgauvin]

Hi @derkoe and @geoffrich, this has now been fixed and you can access the x-ms-client-principal in requests rewritten to an api path. I've forked and edited your repo derkoe, and here it is working: https://github.com/thomasgauvin/azure-swa-auth-issue-with-nav-fallback Try it out! https://yellow-ocean-03d2d7403.3.azurestaticapps.net/thisisa404

[derkoe]

Thx @thomasgauvin - it seems to work now in my application without the workaround.

[thomasgauvin]

Excellent, thanks for the confirmation @derkoe, closing this issue

[MykalMachon]

Hi all,
We're still experiencing this issue. I've yet to try @derkoe 's workaround but it looks like around 30-40% of our requests are going to the API without the x-ms-client-principal header which makes our app unusable in production.

I can't share our application code with this thread as it's internal, but this only happens in one of our 2 environments.
Our test resource group has no issues while our production one has had issues since it was deployed.

What is the best way to get this sorted?

Edit: I tried @derkoe's suggestion and it still looks like around 30-40% of my API requests are forwarded to my container app without the x-ms-client-principal header

[ajames88]

I am also experiencing the same issue as @MykalMachon in a Azure SWA which is receiving 401 Unauthorized responses from a connected Azure Container App which host our APIs.

Is there an easy to prevent this intermittent issue?

Issue also raised at: https://learn.microsoft.com/en-us/answers/questions/1635634/x-ms-client-principal-header-not-included-in-reque