Adding ResponseCacheAttribute to MVC global filter list does not apply to Razor Pages · Issue #18890 · dotnet/aspnetcore (original) (raw)

I was about to make this feature request, but quickly searched for a similar issue. I was happy to see that this issue was already reported in #14917. Unfortunately, that issue is already locked down, so therefore I'm raising this issue again.

To answer @pranavkm question:

@sebnilsson is there a reason you are unable to use ResposeCacheAttribute? It's how we expect users to configure the filter on their endpoints.

No, there is not. We've added the attribute, and that works. However, we don't want to use the filter in such a way, since we encountered a security issue in conjunction with Azure FrontDoor (see below). So we would want to turn off caching for all pages. Using the attribute on all pages is tedious, and opens up forgetting this attribute on a page, resulting in a security vulnerability.

We've implemented a page filter now, but would much rather like to use the built-in action filter, since that also validates the cache control parameters. In case we ever would change the caching behavior, we would get validation from the built-in filter, if we misconfigure that.

Additional context: security issue

We're developing an application that authenticates with AzureAD. This uses the standard services.AddAuthentication(AzureADDefaults.AuthenticationScheme).AddAzureAD();, as provided with the New Project template. In front of that, we've added Azure FrontDoor, and when we enabled that, we noticed that we would get someone elses logged in page.

We tracked that down to being related to the caching of Azure FrontDoor: .AddAzureAD() uses the CookieAuthenticationHandler for signing you in. When you then subsequently open a page with the authentication cookie being set, then your page gets cached for everyone, and you see someone elses pages. This is because FrontDoor will cache the first page, of the first user, and when the second user opens up the application, then it will serve the response of the first user.

In case you're wondering why we're using Azure FrontDoor, and how. We're using Azure Front Door primarily for the WAF, and DDos protection features. But it's also nice it's capable of acting as a CDN. So we still want static assets to be cached by FrontDoor. We could disable the caching for now, to circumvent this problem. Thought, you'd have the same problem with a different caching proxy server in front of this. So it seems to me that this needs to be solved in on the side of the webapplication, and not Azure FrontDoor.