Aspnetcore.docs: Authenticated response caching is not supported?

[jholovacs]

Why? It seems quite silly to make the assumption that authenticated clients would not want or need a caching mechanism. How much of what we do with web api's does not require authentication?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: b6728e59-93ec-891e-0416-94819296ad72
• Version Independent ID: 5d581acc-c651-2112-844a-6b85dc5a99a6
• Content: Response caching in ASP.NET Core
• Content Source: aspnetcore/performance/caching/response.md
• Product: asp.net-core
• GitHub Login: @Rick-Anderson
• Microsoft Alias: riande

[Rick-Anderson]

@jholovacs is this your question?

Warning

Disable caching for content that contains information for authenticated clients. Caching should only be enabled for content that doesn't change based on a user's identity or whether a user is signed in.

[jholovacs]

It's related to that warning, more to the nature of "why would there be a
caching mechanism that would not allow you to use it in a significant
number of cases where it would be desirable to use?" I don't have a case
study in front of me, but it seems that most api calls written nowadays are
authenticated in some manner, or should be.

On Sun, Jun 3, 2018 at 3:49 PM, Rick Anderson [e-mail]
wrote:

@jholovacs https://github.com/jholovacs is this your question?

Warning

Disable caching for content that contains information for authenticated
clients. Caching should only be enabled for content that doesn't change
based on a user's identity or whether a user is signed in.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Docs/issues/6836#issuecomment-394186489, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABr4dEClQjOtnWx75PkgRH6eDUOP1d3oks5t5D2ugaJpZM4UYLjF
.

[Rick-Anderson]

The warning says Disable caching for content that contains information for authenticated clients. that's it. It doesn't stop you from doing that. It's telling you not to enable caching containing information (personal information, etc).

See https://docs.microsoft.com/en-us/aspnet/core/security/gdpr?view=aspnetcore-2.1

[jholovacs]

... and how is that significantly different from previously stated? We're
still in the realm of, "here's this nifty means of caching stuff so you
don't have to hit the database all the time, but oh yeah don't use it on
anything if you care about security at all, which should be darn near
everyone"... no matter how I look at this, it seems a strange architecture
choice. Since authentication verification is unrelated, why not allow the
authentication to happen first if an authentication mechanism exists, and
then return cached objects afterwards? I do not see the reason to make
this an either/ or scenario.

On Sun, Jun 3, 2018 at 5:26 PM, Rick Anderson [e-mail]
wrote:

The warning says Disable caching for content that contains information
for authenticated clients. that's it. It doesn't stop you from doing
that. It's telling you not to enable caching containing information
(personal information, etc).

See https://docs.microsoft.com/en-us/aspnet/core/security/gdpr?
view=aspnetcore-2.1

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Docs/issues/6836#issuecomment-394192733, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABr4dLrvyatjTWurXdX5evh0zm76eKPzks5t5FSLgaJpZM4UYLjF
.

[zihotki]

I also don't quite understand reasons why caching for authenticated clients is not supported. IMO there are no reasons to not support it for particular authenticated client (like VaryByApiKey with possible combination with other VaryByQuery). It seems like a valid scenario to me. Can somebody please elaborate?
Also from what I know when you use standard middleware for response caching it won't cache authenticated responses, according https://docs.microsoft.com/en-us/aspnet/core/performance/caching/middleware?view=aspnetcore-2.1#conditions-for-caching . Documentation implicitly tells to not use caching in such scenario without why's or guidance of enabling proper caching of authenticated requests.

[Rick-Anderson]

Thanks for contacting us.
We don’t have the resources to invest in this area, so we are closing the issue. Should your request generate enough 👍 responses, we’ll reconsider.

[ErikNoren]

I think that warning is general to HTTP caching concerns, not specific to ASP.NET Core. This document explains how to implement caching in ASP.NET Core for a person who knows what they're trying to accomplish. Information on HTTP caching, potential issues, etc. are quite extensive and would appear to be outside the scope of this document. It might be good if the warning had a link out to a resource that explains the issue though so people could more easily get the information they need to resolve the concern the warning raises.

From what I would guess though, this is referencing the proxy cache problem (which might also be a problem with the middleware server-side caching). To illustrate one example:

User A makes a request to server using a general URL.

Server sees User A has made the request and responds with data customized to what User A can see. It knows the content won't change for some time so it tacks on cache headers to let the browser know the response can be stored and future requests within a certain time can be satisfied from the local cache.

A proxy appliance (or server-side caching middleware?) between the user and server observes the request and notes the response headers say the conent is static for some time.

User B makes a request to the server using the same general URL.

The proxy appliance notes the request exactly matches a previous requests, it notes is has a response cached that is still valid and responds with that. The server (your controller) is never aware the request was made because the proxy handled it.

User B now has User A's data.

This problem used to be much worse a long time ago when sites didn't use HTTPS and proxy appliances were aggressive and misconfigured but it's still a potential issue in various situations and might be applicable to the server-side cache that responds directly without calling your controller methods. From the point of view of this document telling people how to configure the caching in ASP.NET Core, the warning is a good shortcut to make people aware there is a concern they should be aware of in case they didn't first start with understanding fully what and how HTTP caching works and is just expecting the library to take care of it all for them.

The doc would be improved by linking the warning to a more comprehensive document on caching and specifically the problem around authenticated (or really user-specific) content in my opinion to help people find a good explanation on the problem and the right way to handle it.

[zihotki]

A proxy appliance (or server-side caching middleware?) between the user and server observes the request and notes the response headers say the conent is static for some time.

Isn't 'private' cache control directive addresses that?

This problem used to be much worse a long time ago when sites didn't use HTTPS and proxy appliances were aggressive and misconfigured but it's still a potential issue in various situations and might be applicable to the server-side cache that responds directly without calling your controller methods.

But it's 2019 now, I assume all caching solutions have fully adopted the standard and it's not possible to have a completely bullet-proof solution since, like you said, proxy can be misconfigured and even apply cache for non-cachable private resources. IMO, Trying to workaround possible misconfigurations is a dead end, it's better to assume the standard.

And as far as I understand, the original question was not in regards with documentation but with the implementation. Currently it completely disables cache for such scenarios and even if you know what you are doing you'll not be able to configure it, you'll have to redo the whole caching layer.

[aseelawi]

its mentioned here as warning
https://docs.microsoft.com/en-us/aspnet/core/performance/caching/response?view=aspnetcore-3.1

but it's mentioned clearly that its disabled in the middleware section "Authorization | The response isn't cached if the header exists." !
https://docs.microsoft.com/en-us/aspnet/core/performance/caching/middleware?view=aspnetcore-3.1

however , I've tried it and it is working fine even if there is Authorization attribute on my controller .

the question here , is it OK to use VaryByHeader = "Authorization" to avoid mixing cached data between different users ?

[joaoantunes]

@aseelawi whenever I pass an Authorization header, it simply ignores the caching.
And that is written on the documentation

"The Authorization header must not be present."

I'm using OAuth Client Credentials Flow, to ensure the protection of the APIs. Is not a user authentication but a Machine!
So it should use caching because there is no difference in the requests/responses between different machines, but is this Microsoft rules I can't use their caching middleware.

So the only alternative that I see is to implement my own Middleware/Attributes.