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

Thanks for your suggestions - I'll consider them each.

>>>>
>>>> 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

--
Juha