-----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----- _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
