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

You have a loop.
The HTTP 302 code says to the browser: re-fetch the content
and use the new URL.

So, when you rewrite www.example.com to 302:www.example.com/?foo=bar
it works well, goes back to the browser and the browser does a
GET www.example.com/?foo=bar which gets processed by Squid and
also goes to the URL rewriter.

So, do not use 302 or make the URL rewritor more intelligent to NOT
rewrite/redirect the already rewritten URL (www.example.com/?foo=bar).

Marcus

On 05/27/2013 10:06 AM, 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.
>
>
> Br,
> Juha
>
>
Received on Mon May 27 2013 - 19:54:47 MDT