Re: [squid-users] question on external_acl_type

On 31/01/2005, at 5:48 PM, Norio Korekawa wrote:

> Hi Scott,
>
> Thank you for your prompt reply.
>
>>> Hello,
>>>
>>> I have a question on external_acl_type and I hope someone will kindly
>>> give me comments or answers.
>>>
>>> Firstly, my squid is Squid Cache: Version 2.5.STABLE1, I'm running
>>> it on Red Hat Linux release 9 (Shrike) and the basic part of my
>>> squid.conf is as follows:
>>>
>>>
>>> --- my squid.conf ---
>>> auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd
>>> auth_param basic children 5
>>> auth_param basic realm Squid proxy-caching web server
>>> auth_param basic credentialsttl 2 hours
>>>
>>> external_acl_type myacltype %LOGIN %SRC %DST %{Referer} %{User-Agent}
>>> /usr/lib/squid/myaclhelper.pl
>>> acl myacl external myacltype
>>>
>>> acl user_auth_acl proxy_auth REQUIRED
>>> http_access deny !user_auth_acl
>>
>> I think this should be closer to
>>
>> http_access allow user_auth_acl myacl
>>
>> This way it is an AND statement as at the moment it is actually an OR
>> statement
>
> I see. I tried your http_access statement above, but the result seemed
> to be same. So I think the following 1. and 2. are equivalent, of
> course,
> 1. is much better.
>
> 1. http_access allow user_auth_acl myacl
>
This could possibly benefit from a

http_access deny all

afterwards looking at it closer.. although the basis of the final rule
being opposite means that it is a deny anyway

> 2. http_access deny !user_auth_acl
> http_access deny !myacl
> http_access allow all
>
Based on the above comment this actually has a fall through allowing
anything that does not get caught in the above 2 statements.

>
>>> http_access deny !myacl
>>> http_access allow all
>>> --- my squid.conf ---
>>>
>>>
>>> My question is:
>>>
>>> It seems that myaclhelper.pl is called by squid, every time new URL
>>> is accessed, but is this correct action? I think it should not be
>>> called, once myacl passes, that is, myaclhelper.pl returns "OK".
>>> In fact, ncsa_auth seems not to be called, once HTTP basic
>>> authentication
>>> passes...
>>>
>> There is another option that specifies how long the helper caches it
>> data for....
>>
>> external_acl_type myacltype ttl=600 %LOGIN %SRC %DST %{Referer}
>> %{User-Agent} /usr/lib/squid/myaclhelper.pl
>>
>> Where 600 is the cached answer timer.
>>
>> For testing I normally set it really low so that the responses are
>> almost real-time but in the real world this creates way too much
>> overhead.
>
> Yes, I already tried ttl with the following statement, but the result
> did not change... If this was true, I think myaclhelper.pl would not
> be kicked by squid within one hour after myacl passes. Or is this my
> misunderstanding...?
>
> external_acl_type myacltype ttl=3600 negative_ttl=120 %LOGIN %SRC %DST
> %{Referer} %{User-Agent} /usr/lib/squid/myaclhelper.pl
>
> # ttl=n TTL in seconds for cached results (defaults to
> 3600
> # for 1 hour)
>
> Thanks.
> Norio
>

I think you are understanding rightly.. the ttl is the timer for the
helper, meaning that the helper has a cache and that cache is cleared
when the ttl of the helper is expired

I think the helper is destroyed and a new one is spawned at this
point...

>>> I think my squid.conf has some problems, but I don't know what they
>>> are...
>>>
>>> Any answer would be appreciated.
>>> Thanks in advance.
>>> Norio
>>
>>
>> This email and any files transmitted with it are confidential and
>> intended solely for the
>> use of the individual or entity to whom they are addressed. Please
>> notify the sender
>> immediately by email if you have received this email by mistake and
>> delete this email
>> from your system. Please note that any views or opinions presented in
>> this email are solely
>> those of the author and do not necessarily represent those of the
>> organisation.
>> Finally, the recipient should check this email and any attachments
>> for the presence of
>> viruses. The organisation accepts no liability for any damage caused
>> by any virus
>> transmitted by this email.
Received on Mon Jan 31 2005 - 00:02:28 MST