trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miles Libbey <>
Subject Re: Programmatically evicting cached resources that match an Authorization header
Date Wed, 23 Nov 2016 16:27:17 GMT
We use the AuthProxy plugin for a similar case.
The request comes in to ATS, it forwards on a HEAD request to an
authorization service. If the authorization service returns 200 OK,
then the object is released from cache. If the auth service gives an
error, then the error is passed back to the user. The downside of this
approach is that it causes an extra roundtrip for each request.  Then
again, without a custom plugin that does your authentication, serving
from cache without true authorization would likely be subject to
replay attacks.

While the Vary header can be used for such a plan, ATS' implementation
only allows for 5 variants -- it sounds like you'd have much more than
that (remembering that various compressions would multiply the
variants).  Instead, perhaps you could use the cachekey plugin
to include the authorization header in the cache key.


On Wed, Nov 23, 2016 at 4:15 AM, Sudheer Vinukonda
<> wrote:
> ATS supports HTTP PURGE method to remove the contents from the cache based
> on the request URL.
> Another more efficient approach is to simply alter the cache key for the
> associated resource to something that's different from the current.
> There's no direct out of the box (via config or a built in plugin) that can
> purge based on a request header, AFAIK. However, using the available TS API,
> it should be simple enough to write a custom plugin that can do it.
> Below are some relevant example plugins that invalidate cache entries
> efficiently by altering the associated cache keys.
> - Sudheer
> On Nov 23, 2016, at 2:25 AM, Pachler, Uwe <> wrote:
> Hello,
> I'm considering to use a HTTP Cache in front of a web application I'm
> developing. I'd operate the cache as a transparent proxy to cache dynamic
> resources that are only accessible via authentication (with Vary:
> Authorization header set, so each user's version is cached separately). What
> a user can and can't see depends on permissions configured for that user in
> the web application, and permissions can change over time. Authentication is
> handled only by the web application.
> From what I've read Apache TS would fit this scenario perfectly, but there
> is an open question I could not find an answer for: If a user's permission
> to see a resource is revoked in the web application, that resource is still
> cached until it becomes stale, so it is still visible. So that change in
> permissions is not in effect as long as the resource is still considered
> fresh by the cache.
> However, because the web application knows when a users permissions change,
> it could simply tell the cache to invalidate (evict) all resources in the
> cache that match the user's authorization header.
> So is there a way to programmatically (e.g. HTTP service call, etc.) evict
> all resources matching an Authorization header?
> Kind regards,
> Uwe

View raw message