.....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 <[email protected]> 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 > <[email protected]> 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 <[email protected]> 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 >>
