Re: [squid-users] Rewriting URL after the ACL check

On 28/05/2013 1:06 a.m., Juha Mustonen wrote:
>>> Is it possible to rewrite the URL *after* the ACL checks? I'm putting
>>> an extra argument into URL (for ACL) - but they aren't needed after
>>> the proxy. So I'm trying to use rewrite for stripping the argument -
>>> but it seems the ACL checks are done after done after the rewrites,
>>> despite the order.
>>
>> Squid does check the http_access controls before the url_rewrite_program is
>> used. If you are finding otherwise, please produce the output of "squid -v"
>> and some details of what you are seeing.
> Well, somehow it get redirected to deny_info URL
>
>
> # ACL
> REQ: http://www.osnews.com/
> DENIED: http://www.osnews.com/
> REDIRECT: http://myservice/?req=http%3A%2F%2Fwww.osnews.com%2F%3F
> REDIRECT: http://www.osnews.com/?key=foo
>
> # URL rewrite
> REDIRECT: http://www.osnews.com/?
>
> # ACL kicks in again...
> DENIED: http://www.osnews.com/
> REDIRECT: http://myservice/?req=http%3A%2F%2Fwww.osnews.com%2F%3F
> ...
>
> And finally browser cancel the request because of too many redirects.
>
> url_rewrite_program is not very well documented, my helper is returning:
>
> REDIRECT: 302:http://www.osnews.com/
> NOCHANGE: http://www.osnews.com
>
> And here's the version info:
>
> Squid Cache: Version 3.3.4
> configure options: '--build=x86_64-linux-gnu' '--prefix=/usr'
> '--includedir=${prefix}/include' '--mandir=${prefix}/share/man'
> '--infodir=${prefix}/share/info' '--sysconfdir=/etc'
> '--localstatedir=/var' '--libexecdir=${prefix}/lib/squid3'
> '--srcdir=.' '--disable-maintainer-mode'
> '--disable-dependency-tracking' '--disable-silent-rules'
> '--datadir=/usr/share/squid3' '--sysconfdir=/etc/squid3'
> '--mandir=/usr/share/man' '--with-cppunit-basedir=/usr'
> '--enable-inline' '--enable-async-io=8'
> '--enable-storeio=ufs,aufs,diskd' '--enable-removal-policies=lru,heap'
> '--enable-delay-pools' '--enable-cache-digests' '--enable-underscores'
> '--enable-icap-client' '--enable-follow-x-forwarded-for'
> '--enable-auth'
> '--enable-basic-auth-helpers=LDAP,MSNT,NCSA,PAM,SASL,SMB,YP,DB,POP3,getpwnam,squid_radius_auth,multi-domain-NTLM'
> '--enable-ntlm-auth-helpers=smb_lm,'
> '--enable-digest-auth-helpers=ldap,password'
> '--enable-negotiate-auth-helpers=squid_kerb_auth'
> '--enable-external-acl-helpers=ip_user,ldap_group,session,unix_group,wbinfo_group'
> '--enable-arp-acl' '--enable-esi' '--enable-zph-qos' '--enable-wccpv2'
> '--disable-translation' '--with-logdir=/var/log/squid3'
> '--with-pidfile=/var/run/squid3.pid' '--with-filedescriptors=65536'
> '--with-large-files' '--with-default-user=proxy'
> '--enable-linux-netfilter' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g
> -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Wformat-security -Werror=format-security -Wall'
> 'LDFLAGS=-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now'
> 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -fPIE
> -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security
> -Werror=format-security'
>
>
>> BTW: this is an *extremely* nasty abuse of HTTP. Please reconsider using an
>> HTTP header to pass this information.
>>
> Thanks for the suggestion, I'm aware this solution is not ideal. What
> I'm trying to achieve is cookie based authorisation. Because the
> client IP address is behind NAT, I can't identify them using it. And
> using authentication dialog is no-go as well. I already tried setting
> the cookie from same address where the proxy is running, but
> apparently browsers do not send cookies to proxy when connecting
> another site. So working with the URL seemed only way to go.

Erm, yes. Cookies are browser-server private state data. Browsers will
no more send Cookies to a different origin server (or known proxy) than
they will send proxy credentials to a proxy which is intercepting
browser-server connections.

Authetication dialog/popup is *not* part of HTTP. It is purely a feature
of web browsers. If the client browser is able to locate credentials via
means other than asking the user for help it will not appear. So....

* You may want to look at issuing Kerberos tickets to your clients and
setting up Negotiate auth.

* Another alternative that works is stunnel from the client box to the
proxy https_port with client certificate validation. The browser then
just uses the stunnel as an open HTTP proxy and the real proxy uses the
client cert to identify who it is.

Amos
Received on Tue May 28 2013 - 05:51:20 MDT