On Tue, 2011-10-18 at 14:44 +0300, Alex F wrote: > Hello, > > I am trying to set up a splash page as an initial page, no matter what > users request. > Please note I am using Squid 3.2 with session helper 1.1 on debian 6. > Following the examples from > http://wiki.squid-cache.org/ConfigExamples/Portal/Splash I have > managed to set up and get results with the first example. > Scrolling down, there is the second example on how to enforce a check > that the user did GET a specific page. > I've got the following set up: > __________ > external_acl_type session_LOGIN_master concurrency=100 ttl=2 %SRC > /usr/local/squid3.2/libexec/ext_session_acl -T 30 -b > /usr/local/squid3.2/lib/session.db -a > acl session_LOGIN external session_LOGIN_master LOGIN > > external_acl_type session_ACTIVE_master concurrency=100 ttl=2 %SRC > /usr/local/squid3.2/libexec/ext_session_acl -T 30 -b > /usr/local/squid3.2/lib/session.db -a > acl session_is_ACTIVE external session_ACTIVE_master > > acl A dstdomain 192.168.235.136 > acl B urlpath_regex /splash.html /check.html > http_access allow A B The above 2 rules do not appear to be used? > > acl clicked_login_url url_regex -i http://192.168.235.136/check.html > http_access allow clicked_login_url session_LOGIN This all looks correct to me. However, I would run a test yourself from a shell. Just run the session helper yourself from a command prompt and enter the IP address of your computer to test it: /usr/local/squid3.2/libexec/ext_session_acl -T 30 -b /usr/local/squid3.2/lib/session.db -a Then type: 10 192.168.0.1 [change IP address as appropriate] You should either get OK or ERR in response > > http_access deny !session_is_ACTIVE > deny_info http://192.168.235.136/splash.html session_is_ACTIVE > __________ > > BTW, note that in the example page, at the "# If we get here, URL not > present" section there is "http_access deny session_day > !session_is_active" - session_day ACL does NOT exist anywhere. May be > a typo or something. Yes, that's a typo. I'll correct that. > I am failing to see what's wrong. Any idea is appreciated. I suspect that the actual problem is a sync problem when running multiple session helpers (they cache the database individually). This problem is fixed with an upgrade to a newer Berkeley DB version in version 1.2 of the session helper, currently waiting acceptance into trunk. In the meantime the patch is available here: http://www3.us.squid-cache.org/mail-archive/squid-dev/201110/0116.html Andy