Hi, Thanks to everyone who have responded in such detail. I have done a proof of concept of the solution using external ACL helper and URL rewriter, and it does what I wanted. Regarding using a token in URL as a way to differentiate between different users, I now understand the implications on downstream caches and overall performance. Thanks for driving home the important point. regards, Sreenath On 11/9/15, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > On 10/11/2015 6:12 a.m., Sreenath BH wrote: >> Hi Alex, >> >> thanks for your detailed asnwers. >> >> Here are more details. >> 1. If the URL does not have any token, we would like to send an error >> message back to the browser/client, without doing a cache lookup, or >> going to backend apache server. >> >> 2. If the token is invalid (that is we can't find it in a database), >> that means we can not serve >> data. In this case we would like to send back a HTTP error (something >> like a 401 or 404, along with a more descriptive message) >> > > All of the above is external_acl_type helper operations. > >> 3. If the token is valid(found), remove the token from the URL, and >> use remaining part of URL as the key to look in Squid cache. >> >> 4. If found return that data, along with proper HTTP status code. > > The above is url_rewrite_program operations. > >> 5. If cache lookup fails(not cached), send HTTP request to back-end >> apache server (removing the token), get returned result, store in >> cache, and return to client/browser. > > And that part is normal caching. Squid will do it by default. > > Except the "removing the token" part. Which was done at step #4 already, > so has no relevance here at step #5. > >> >> I read about ACL helper programs, and it appears I can do arbitrary >> validations in it, so should work. >> Is it correct to assume that the external ACL code runs before url >> rewriting?, > > The http_access tests are run before re-writing. > If the external ACL is one of those http_access tests the answer is yes. > >> >> Does the URL rewriter run before a cache lookup? > > Yes. > > > > Although, please note that despite this workaround for your cache. It > really is *only* your proxy which will work nicely. Every other cache on > the planet will see your applications URLs are being unique and needing > different caching slots. > > This not only wastes cache space for them, but also forces them to pass > extra traffic in the form of full-object fetches at your proxy. Which > raises the bandwidth costs for both them and you far beyond what proper > header based authentication or authorization would. > > As the other sysadmin around the world notice this unnecessarily raised > cost they will start to hack their configs to force-cache the responses > from your application. Which will bypass your protection system entirely > since your proxy may not not even see many of the requests. > > The earlier you can get the application re-design underway to remove the > credentials token from URL, the earlier the external problems and costs > will start to dsappear. > > Amos > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
