Static-web-apps: platformErrorOverrides "Unauthenticated" error type not redirecting to provided route

[chrisbinney]

I may have misunderstood something, but it appears that the "Unauthenticated" error type doesn't work as documented here.

The explanation below the example route file says that unauthenticated users will redirect to the /login route. When I set up an app like that and navigate to the /profile route, instead of redirecting to the /login route it shows the Microsoft Azure default 404 page.

If I navigate directly to the /login route I am able to log in successfully, and if I try /profile again I can access the page successfully.

You can see the example repository I'm using here.

Thank you.

[miwebst]

Hi @chrisbinney, thanks for trying this out!
I took a look at your repository and I believe the confusion is because the platform error overrides does not rerun the route rules, so your override is looking for a login.html file that does not exist.

To get this working for you, I'd suggest adding a 302 redirect to /login for your case. You can just add a line to the unauthenticated platform error override like "statusCode": 302. Please let us know if that fixes the issue.

@craigshoemaker, we should probably make a note of this in our documentation.

[chrisbinney]

Thanks @miwebst!

As you suggested, I added the "statusCode": 301 to the "Unauthenticated" override and that did do the redirect to login! However, if I subsequently try and access the /profile route, it briefly navigates to /.auth/login/done and then back to the root "/". I can't access /profile at all.

It looks as if the the "Unauthenticated" redirect is still occurring even though the user has logged in and has the "authenticated" role.

I've checked the payload from /.auth/me and the user has the "authenticated" role, and I'm not asked to log in again after the first time trying to navigate to /profile.

Is it possible that the authentication state of the user is cached in some way?

[mkarmark]

Hi @chrisbinney,

I hit the following endpoints in the order listed to get the following results:

1. Hit /.auth/me --> I was not logged in, so I saw clientPrincipal: null
2. Hit /profile --> Because I was not logged in, I did not match with the /profile rule. In fact I didn't match with the other two rules either, so got the platform error "Unauthorized". Because there was the "Unauthorized" platform error override provided, I matched with it and redirected to /login. I then matched with the login rule and completed the login flow
3. Hit /.auth/me --> I was now logged in so saw my appropriate clientPrincipal with an "authenticated" role
4. Hit /profile --> because I had the authenticated role, I matched with the /profile rule and saw the desired content

This flow seems to behave correctly based on what the platform offers. Are there any questions/concerns about alternate behavior that may be expected?

Thanks for trying out Azure Static Web Apps, and thanks for your patience!

[chrisbinney]

1-3 are the same for me, but for step 4 I get a different result:

When I navigate to /profile, I don't see the desired content. Instead, it redirects to identity.azurestaticapps.net/.auth/login/done and then back to /.

Curiously, if I open the developer tools then navigation seems to work as expected (this is in Chrome btw).

I've attached a video that shows the issue I'm having.

Static Wen App log in issue.zip

[mkarmark]

So I double checked that everything is working for me from your site even with developer tools not open (both in incognito and non-incognito). However, the fact that everything worked with developer tools open likely means that your developer tools window had "disable cache" checked, and the bad behavior was a result of us caching the old behavior at /purge. After some time now, I would expect the flow to work from any browser now. Is that the case, @chrisbinney?

[craigshoemaker]

@miwebst - I updated the route rule in the example to include the 301 redirect.

[chrisbinney]

Thank you for looking into this.

Just checked again and the problem is still there. However, I've tested it in Edge and it works as expected and I'm able to access the content at /profile. I installed a fresh copy of Firefox to test it and I see the issue in that browser too.

Just to see what would happen, I also tried changing the authentication provider to /.auth/login/aad, and I can still see the problem.

So the issue is still there in Chrome and Firefox, but not in Edge and is reproducible for me across different authentication providers.

[chrisbinney]

@miwebst , I just re-read the initial reply and I realized what's happened. In the text of your reply you suggest using a 302 but your example was to add a "statusCode": 301 line to the routes.json file. I worked off the latter. If I change it to a 302, then the browser, of course, doesn't cache as it's a temporary redirect. So that solves the problem.

WFIW In the longer term it seems like a good idea to me for the overrides to work with the routing rules, but this solution works fine.

It'd be a good idea to update the route docs too, as I notice the statusCode in the example has been set to 301, not a 302.

Thank you for your help!

[miwebst]

@craigshoemaker we should probably make it 302 as it seems like 301 causes a caching issue. We should also make a note on the platform error overrides doc to make it clear that we will not rerun the routing rules here but are looking for the path to the content to serve.

[craigshoemaker]

@miwebst - done

[craigshoemaker]

Please be aware that the _routes.json_ file is deprecated. Routes, overrides and general configuration of a Azure Static Web Apps are now powered by the staticwebapp.config.json file.