On 7/06/24 07:08, Kevin wrote:
>
>> acl trellix_phone_cloud dstdomain amcore-ens.rest.gti.trellix.com
>> http_access deny trellix_phone_cloud
>> external_acl_type host_based_filter children-max=15 ttl=0 0X0P+0CL
>> acl HostBasedRules external host_based_filter
>> http_access allow HostBasedRules
>> auth_param digest program /usr/lib/squid/digest_file_auth -c
/etc/squid/passwd
>> auth_param digest realm squid
>> auth_param digest children 2
>> auth_param basic program /usr/lib/squid/basic_ncsa_auth
/etc/squid/basic_passwd
>> auth_param basic children 2
>> auth_param basic realm squidb
>> auth_param basic credentialsttl 2 hours
>
>> acl auth_users proxy_auth REQUIRED
>> external_acl_type custom_acl_db children-max=15 ttl=0 0X0P+0CL >>
acl CustomAclDB external custom_acl_db
>> http_access allow CustomAclDB
>
>
>Hmm, this use of combined authentication+authorization is a bit tricky
>with two layers of asynchronous helper lookups going on. That alone
>might be what is going on with the weird 403's.
>
>
>A better sequence would be:
>
># ensure login is performed
>http_access deny !auth_users
>
># check the access permissions for whichever user logged in
>http_access allow CustomAclDB
The first call the the external_acl is to process unauthenticated
requests. Is the suggestion to replace
acl auth_users proxy_auth REQUIRED
with
http_access deny !auth_users
before the second external_acl (for authenticated requests)?
No. It is to ensure that "missing credentials" are treated differently
than "bad credentials". Specifically that any auth challenge response is
never able to be given "allow" permission.
HTH
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users