Sorry, but just one more comment.
Well, I just want to use different ERR_ pages for user_auth_acl and
myacl by deny_info, say, ERR_USER_AUTH_FAILED for user_auth_acl and
ERR_MYACL_FAILED for myacl.
In case 1. below, squid shows ERR_USER_AUTH_FAILED for user_auth_acl,
however it shows not ERR_MYACL_FAILED but just ERR_ACCESS_DENIED for myacl...
On the other hand, in case 2. below, everything is fine, squid shows
ERR_USER_AUTH_FAILED for user_auth_acl and ERR_MYACL_FAILED for myacl,
as I expect.
That's why, I'm using the latter case... If you know any mistake
in case 1., I hope anyone will let me know.
--- my squid.conf ---
acl user_auth_acl proxy_auth REQUIRED
external_acl_type myacltype %LOGIN %SRC %DST %{User-Agent} /usr/lib/squid/myaclhelper.pl
acl myacl external myacltype
deny_info ERR_USER_AUTH_FAILED user_auth_acl
deny_info ERR_MYACL_FAILED myacl
#
# case 1.
#
http_access allow user_auth_acl myacl
http_access deny all
#
# case 2.
#
http_access deny !user_auth_acl
http_access deny !myacl
http_access allow all
--- my squid.conf ---
Regards,
Norio
> > 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.
