AntiforgeryValidationException preventing Blazor app to start on IIS Web App. (case sensitive url)

[maiemy]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

The problem start when deploy my Blazor aspnet core 8 app on IIS like the image below.

If I use the url in browser with the same name in the base tag everything works.

If the url is correct but with the web app name with different case I receve the error below. For example portal instead of Portal

could you help me?
I think the url should be case insentitive in the management of the Antiforgery.

thanks

Expected Behavior

I think the url should be case insentitive in the management of the Antiforgery.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

net 8

Anything else?

No response

[MackinnonBuck]

This looks like a DataProtection issue.

[amcasey]

@MackinnonBuck I think you might be saying that the case-sensitivity is a red herring and this is a "normal" data protection error where a subsequent access (generally, on a different instance) fails to decrypt an anti-forgery key? Is that right?

[amcasey]

@maiemy If you make repeated queries, does it always succeed with "Portal" and always fail with "portal"? How many instances does your app have?

[maiemy]

@maiemy If you make repeated queries, does it always succeed with "Portal" and always fail with "portal"? How many instances does your app have?

Yes correct
With the same name likes base tag Always succede. In lowercase fail

I Have only one instance os iis and only one server

[amcasey]

Hmm, it's not immediately clear how that could be a data protection bug. Do you know if anti-forgery is using a different purpose string for each endpoint, @MackinnonBuck?

[amcasey]

@maiemy Are you configuring data protection explicitly, or just using the defaults?

[maiemy]

@maiemy Are you configuring data protection explicitly, or just using the defaults?

Default

[maiemy]

@maiemy Are you configuring data protection explicitly, or just using the defaults?

Configuration summary

IIS run on Windows Server 2022 Standard
Version 21H2
OS build 20348.2582
IIS version 10.0.20348.1

one application pool dedicated to the application. Managed pipeline: managed

program.cs in image

if call in lowercase fail

if call with correct name is ok

this is the log when fail

[amcasey]

Sorry for the delay - I had to fix something in 9.0 RC2 at the last minute.

The log in your last screenshot seems to show a different exception? It appears to be about the lack of middleware, rather than about failing to decrypt the anti-forgery token. Perhaps your reduced repro behaves differently than your full app? Or maybe the decryption failure leads to the middleware being considered unavailable? I can't see that I've seen that before, but I've only looked from the data protection end.

So, if you request lowercase, uppercase, lowercase, uppercase, etc, every call to lowercase fails and every call to uppercase succeeds? Or is it random (which is more common with these key decryption errors)?

[maiemy]

Sorry for the delay - I had to fix something in 9.0 RC2 at the last minute.

The log in your last screenshot seems to show a different exception? It appears to be about the lack of middleware, rather than about failing to decrypt the anti-forgery token. Perhaps your reduced repro behaves differently than your full app? Or maybe the decryption failure leads to the middleware being considered unavailable? I can't see that I've seen that before, but I've only looked from the data protection end.

So, if you request lowercase, uppercase, lowercase, uppercase, etc, every call to lowercase fails and every call to uppercase succeeds? Or is it random (which is more common with these key decryption errors)?

no problem for the delay in replying. :-)

Yes, always fail all calls where the name of the app is not the same as the name entered in the base tag in my application.
i think it's something about the anti-forgery token. in my the old applications i don't get this error. it came with .net8 of which I read that the handling of form edits was changed with the introduction by default of the anti-forgery token