You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by "Pachler, Uwe" <Uw...@datagroup.de> on 2016/11/23 10:25:21 UTC
Programmatically evicting cached resources that match an
Authorization header
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
Re: Programmatically evicting cached resources that match an Authorization header
Posted by Sudheer Vinukonda <su...@yahoo.com>.
.....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 <ml...@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
> <su...@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 <Uw...@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
>>
Re: Programmatically evicting cached resources that match an
Authorization header
Posted by Miles Libbey <ml...@apache.org>.
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
<su...@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 <Uw...@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
>
Re: Programmatically evicting cached resources that match an Authorization header
Posted by Sudheer Vinukonda <su...@yahoo.com>.
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 <Uw...@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
>