trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sudheer Vinukonda <sudheervinuko...@yahoo.com>
Subject Re: Programmatically evicting cached resources that match an Authorization header
Date Wed, 23 Nov 2016 17:07:47 GMT
.....ATS' implementation
> only allows for 5 variants .......

I don't think this is true. I've seen people configure ATS with many more than 5 alternates
(5 is just the default max, which can obviously be raised as needed).

https://docs.trafficserver.apache.org/en/latest/admin-guide/files/records.config.en.html#proxy.config.cache.limits.http.max_alts

Having said that, alternates come at a cost in terms of cache read/updates, so, depending
on the scale/throughput needed, modifying the cache key (using the cachekey plugin that Miles
suggested below) to include request URL + Authorization header could be more efficient for
storing/accessing the cached objects.

- Sudheer

> On Nov 23, 2016, at 8:27 AM, Miles Libbey <mlibbey@apache.org> wrote:
> 
> We use the AuthProxy plugin for a similar case.
> https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/authproxy.en.html
> 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
> https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/cachekey.en.html
> to include the authorization header in the cache key.
> 
> miles
> 
> On Wed, Nov 23, 2016 at 4:15 AM, Sudheer Vinukonda
> <sudheervinukonda@yahoo.com> 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.
>> 
>> https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/remap_purge.en.html
>> 
>> https://github.com/apache/trafficserver/blob/master/plugins/experimental/remap_purge/remap_purge.c
>> 
>> https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/regex_revalidate.en.html
>> 
>> https://github.com/apache/trafficserver/blob/master/plugins/regex_revalidate/regex_revalidate.c
>> 
>> - Sudheer
>> 
>> On Nov 23, 2016, at 2:25 AM, Pachler, Uwe <Uwe.Pachler@datagroup.de> 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
>> 

Mime
View raw message