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) 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. 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. 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?, Does the URL rewriter run before a cache lookup? thanks, Sreenath On 11/8/15, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > On 11/08/2015 06:34 AM, Sreenath BH wrote: > >> Is there a way for me to invoke some custom code for every request >> that Squid receives? > > Yes, there are several interfaces, including a built-in ACL, an external > ACL helper, a URL rewriter, an eCAP/ICAP service. Roughly speaking, the > former ones are easier to use and the latter ones are more powerful. > > >> That script would do the following: >> >> 1. Extract part of the URL(the token) and look up in a database to see >> if it is valid. >> If valid, proceed to lookup cached object, other wise go to >> back-end fetch, etc. >> 2. If the token is not found in database, return with an error, so >> that Squid can send back a not found type (some HTTP error) of >> response. > > If the above are your requirements, avoid the word "authentication" > might help. It confuses people into thinking you want something far more > complex. > > > The validation in step #1 can be done by an external ACL. However, you > probably forgot to mention that the found token should be removed from > the URL. To edit the URL, you need to use a URL rewriter or an eCAP/ICAP > service. > > Everything else can be done by built-in ACLs unless you need to serve > very custom error messages. In the latter case, you will need an eCAP or > ICAP service. > > However, if "go to back-end fetch" means loading response from some > storage external to Squid without using HTTP, then you need an eCAP or > ICAP service to do that fetching. > > I recommend that you clarify these parts of your specs: > > What do you want to do when the token is not found in the URL? > > What do you want to do when an invalid token is found in the URL? > > Will sending a response using a simple template filled with some basic > request details suffice when a valid token is not found in the database? > > > HTH, > > Alex. > > > >> On 7/11/2015 1:33 a.m., Sreenath BH wrote: >>> Hi >>> I am very new to Squid, and think have a strange requirement. >>> We want to serve cached content only if the client has been >>> authenticated before. >>> Since we don't expect the client software to send any information in >>> headers, we embed a token in the URL that we present to the user. >>> >> >> Um, you know how sending username and password in plain-text Basic auth >> headers is supposed to be the worst form of security around? >> >> It's not quite. Sending credentials in the URL is worse. Even if its >> just an encoded token. >> >> Why are you avoiding actual HTTP authentication? >> >> Why be so actively hostile to every other cache in existence? >> >> >>> So when the client s/w uses this URL, we want to extract the token >>> from URL and do a small database query to ensure that the token is >>> valid. >>> >>> This is in accelerator mode. >>> Is it possible to use something similar to basic_fake_auth and put my >>> code there that does some database query? >> >> The "basic_..._auth" parts of that helpers name mean that it performs >> HTTP Basic authentication. >> >> The "fake" part means that it does not perform any kind of validation. >> >> All of the text above has been describing how you want to perform >> actions which are the direct opposite of everything basic_fake_auth does. >> >>> If the query fails, we don't return the cached content? >> >> What do you want to be delivered instead? >> >> 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
