[squid-users] Unable to display splash page on inactive timeout

[Amos Jeffries]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15/10/2014 8:31 p.m., santosh wrote:
> Hello Team,
> 
> I have set-up a squid proxy server and have implemented the URL
> blocking and authentication through ldap successfully . Now i have
> a requirement that the squid proxy has to timeout inactive
> authenticated sessions informing the user to re-login. I followed
> up the below links as below
> 
> http://wiki.squid-cache.org/ConfigExamples/Portal/Splash 
> http://thejimmahknows.com/squid-proxy-splash-page-2/
> 
> have tried different combinations and i'm not able to make it to
> work , i Have posted the acl as below please let me know wherei'm
> going wrong
> 

You started going wrong with the assumption that there *are*
authentication sessions in HTTP.  Once you realise there are no
sessions, then its clear there is no way for then to become "inactive".

HTTP is stateless at the protocol messaging level. Every request
involving authentication MUST have the relevant credentials sent
explicitly so as to re-authenticate them per-request.

So, Squid is always getting "fresh" credentials from the client. The
TTL relavant to Squid (helper TTL value) is just how often it has to
re-validate that constant incoming stream with the backend for
changes, versus comparing against its prevously cached auth result.
 - this happens during "allow ldapauth" so Squid never gets to any
not-logged-in state for valid users at the "deny !existing_users"
check. So move your existing_users check above the auth check.
 - even if you get this 511 result back to the client, bad things will
happen.


Basic auth has a binary respone to the client. Which states only
OK/allowed or 407-DENIED/invalid credentials.

Digest auth offers something closer to a session mechanism where Squid
can explicitly send the client a nonce-expired/stale marker to the
client instead of just rejecting the credentials as invalid.

Both of these are handled automatically behind the scenery in the
authentication logics. The human user should never be bothered more
than once per connection for credentials.


Additional to that...

Your requirement is a bit of a nasty idea due to the fact that web
"pages" do not actually exist as objects being requested. What *will*
happen is that some random object used to create a page will be
replaced by the session re-login "page" you are sending.

That is not necessarily going to be visible to the user. If it does
happen by chance to replace an HTML object or image, maybe. But a
large proportion of web content is actually scripts, CSS, or data
objects parsed and processed by scripts in the browser to display some
other visible content. Replacing any one of those with an arbitrary
HTML object is potentially dangerous or at best screwing up the client
experience badly without the re-login info actually being made visible.
 - once it has been sent and done its damage the very next client
request continues on with the same old credentials in the new session
period.


> # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS #
> 
> external_acl_type splash_page ttl=60 concurrency=100 %SRC 
> /usr/lib/squid3/ext_session_acl -t 80 -b
> /usr/lib/squid3/session.db
> 
> acl existing_users external splash_page
> 
> auth_param basic program /usr/lib/squid3/basic_ldap_auth -b 
> "dc=example,dc=com" -f "(|(uid=%s)(mail=%s))" -h proxy.example.com
> 
> acl ldapauth proxy_auth REQUIRED acl bad_url url_regex
> "/etc/squid3/badsites.conf"
> 
> http_access deny bad_url http_access allow ldapauth http_access
> deny !existing_users deny_info 511:/var/www/html/info.php
> existing_users
> 

Regarding the 511 usage. It is intended for situations where
407/proxy-auth is not possible. When authentication has to be done
*entirely* by an external_acl_type helper, (eg  when intercepting
traffic).

The 407 message itself has essentially the same meaning as 511, but
triggers the client software to use proxy-auth headers in future
requests. Whereas 511 implies that something else (like cookies) are
being used to convey the credentials - but no HTTP level information
is contained about what that mechanism might actually be.

Amos

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUPjvMAAoJELJo5wb/XPRjhj0H/jz9sSy2d9EQB4uQyy+7d6Rt
cGeZAo8MsgAuvT0V1p3H1a9HZrp5lmiIevs7dn3bpIXC22wMgjd0Tq0lp4coGw6R
a4ufSZrGdwEMB/9BNqsXW3rSncIQ2Dr4JfgPeM/dCkS2hDxo4XKWM8nOxDq9MEEX
7y3Q8t99Y7fV1VLnGeq1R1Dk6oZzku5veouLVxFaiiKWsQH3FKm7pbi8+5ridr4E
M4XPEUk9kMAqZ5Un9bpEEarbLYjD/xA5Cz1l7NPPZXr+sTK+brsi4ET7uo02Lh8+
B4K0BOHwt/Xu57zmjJhxJSIPw+PcFDdWKwghLc0z1X1DycPI59cBiidS0/sYgUk=
=kMPD
-----END PGP SIGNATURE-----