Re: Policy with multiple ACL calls
Andrey K <[email protected]> Thu, 26 Mar 2026 03:49:12 +0300
| Newsgroups | gmane.comp.web.squid.general |
|---|---|
| Message-ID | <CADJd0Y1PCT0WuDLnfQxpZO1FbDA0YwAKw1+Oo6j7X13rLK=EHg@mail.gmail.com> |
--===============5002466921494538663==
Content-Type: multipart/alternative; boundary="0000000000007b76b1064de2c160"
--0000000000007b76b1064de2c160
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hello, Amos,
Thanks for the clarification! I get it now.
Kind regards,
Ankor
=D1=87=D1=82, 26 =D0=BC=D0=B0=D1=80. 2026=E2=80=AF=D0=B3. =D0=B2 00:20, Amo=
s Jeffries <[email protected]>:
> On 26/03/2026 02:29, Andrey K wrote:
> >
> > Hello, Amos,
> >
> > Thank you so much for such a detailed answer.
> >
> > > > > > http_access allow is_bank user1 all
> > > > > >
> > > > > > ssl_bump splice is_bank user1 all
> > > >
> > > > I thought that re-authentication only occurs during a deny action
> > within
> > > > http_access directives when the final ACL is authentication-based.
> If
> > > > so, the "all ACL" hack should only be applied to those specific
> rules,
> > > > correct?
> > >
> > > The authentication is still re-checked by Squid on every ACL test.
> > > There are a login cache, and helper result cache preventing the clie=
nt
> > > agent and user being bothered by this frequent re-test.
> > >
> > > However, if either of those cached entries expire, then the auth
> system
> > > gets involved again immediately regardless of previous check results=
.
> >
> > I am sorry, but I still don=E2=80=99t quite understand why we should us=
e "all-
> > hack" at the end of "http_access allow auth-acl" rules.
>
> Sorry, just me being dumb and treating them like "deny" lines.
> The "all" is indeed irrelevant on "allow" lines.
>
> Cheers
> Amos
>
>
--0000000000007b76b1064de2c160
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello, Amos,<div><br></div><div>Thanks for the clarificati=
on! I get it now.</div><div><br></div><div>Kind=C2=A0regards,</div><div>=C2=
=A0 =C2=A0 Ankor</div></div><br><div class=3D"gmail_quote gmail_quote_conta=
iner"><div dir=3D"ltr" class=3D"gmail_attr">=D1=87=D1=82, 26 =D0=BC=D0=B0=
=D1=80. 2026=E2=80=AF=D0=B3. =D0=B2 00:20, Amos Jeffries <<a href=3D"mai=
lto:[email protected]">[email protected]</a>>:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">On 26/03/2026 02:29, Andrey K wrote=
:<br>
> <br>
> Hello, Amos,<br>
> <br>
> Thank you so much for such a detailed answer.<br>
> <br>
>=C2=A0 > >=C2=A0 > > =C2=A0http_access allow is_bank user1 =
all<br>
>=C2=A0 > >=C2=A0 > ><br>
>=C2=A0 > >=C2=A0 > > =C2=A0ssl_bump splice =C2=A0 =C2=A0is_=
bank user1 all<br>
>=C2=A0 > ><br>
>=C2=A0 > > I thought that re-authentication only occurs during a =
deny action <br>
> within<br>
>=C2=A0 > > http_access directives when the final ACL is authentic=
ation-based. If<br>
>=C2=A0 > > so, the "all ACL" hack should only be applie=
d to those specific rules,<br>
>=C2=A0 > > correct?<br>
>=C2=A0 ><br>
>=C2=A0 > The authentication is still re-checked by Squid on every AC=
L test.<br>
>=C2=A0 > There are a login cache, and helper result cache preventing=
the client<br>
>=C2=A0 > agent and user being bothered by this frequent re-test.<br>
>=C2=A0 ><br>
>=C2=A0 > However, if either of those cached entries expire, then the=
auth system<br>
>=C2=A0 > gets involved again immediately regardless of previous chec=
k results.<br>
> <br>
> I am sorry, but I still don=E2=80=99t quite understand why we should u=
se "all- <br>
> hack" at the end of "http_access allow auth-acl" rules.=
<br>
<br>
Sorry, just me being dumb and treating them like "deny" lines.<br=
>
The "all" is indeed irrelevant on "allow" lines.<br>
<br>
Cheers<br>
Amos<br>
<br>
</blockquote></div>
--0000000000007b76b1064de2c160--
--===============5002466921494538663==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
squid-users mailing list
[email protected]
https://lists.squid-cache.org/listinfo/squid-users
--===============5002466921494538663==--