On 24/06/19 5:04 am, julien412@xxxxxxxx wrote: > Hello, > > I'm trying to use Squid with Splash page and followed > https://wiki.squid-cache.org/ConfigExamples/Portal/Splash but I've got > an issue with a redirection loop. > Connecting to any web site redirects to splash page but splash page is > redirected to itself in infinite loop until squid breaks it. > > This happens on Centos7/Squid 3.5.20, Ubuntu bionic/3.5.27 or 4.4 source > build. > > Installed with ansible role with travis testing failing on redirection > https://travis-ci.org/juju4/ansible-squid/jobs/549377518 > > This part should not happen > +< HTTP/1.1 302 Found > +< Server: squid/3.5.27 > +< Mime-Version: 1.0 > +< Date: Sun, 23 Jun 2019 15:04:22 GMT > +< Content-Type: text/html;charset=utf-8 > +< Content-Length: 0 > +< Location: > http://localhost/splash.php?url=http%3A%2F%2Flocalhost%2Fsplash.php%3Furl%3Dhttp%253A%252F%252Fwww.google.com%252F > +< X-Squid-Error: 403 Access Denied > +< X-Cache: MISS from default-splash-ubuntu-1804-1561301803 > +< X-Cache-Lookup: NONE from > default-splash-ubuntu-1804-1561301803:3128 > +< Connection: keep-alive > > Config extract > external_acl_type splash_page ttl=60 concurrency=100 %SRC > /usr/lib/squid/ext_session_acl -t 7200 -b /var/lib/squid/session.db > acl existing_users external splash_page > deny_info http://localhost/splash.php?url=%s existing_users > http_access deny !existing_users > > Any advices? Couple of things: * this is a localhost URL. The client is expected to contact *its* localhost, not use the proxy for the followup request. But that is not related to the loop here. * you need to check access.log to see whether the client src-IP is changing between requests. If it does that is the cause of the loop. - the test is broken: it configures Squid to send data to access_custom.log *instead* of access.log, then tries to use the empty access.log as the test log output. * please add "-d" to the session helper command line options. That should show what the helper is doing to declare "no session" when the client feeds back the splash URL to the proxy. PS. If I am reading the PR which is being tested - it looks like it changes the check from one which checks; - the Location URL being redirected to the splash page => OK - the Location URL looping => BAD - all non-splash URLs => BAD to; - the Location has *any* URL which includes the splash page => OK (corollary: - the Location URL looping => OK !!) - all non-splash URLs => BAD Squid is only failing this test because v3.5 eventually rejects one of the 8KB+ long URLs generated by the loop. There are problems with the underlying helper tests too: describe command('echo 10.0.0.1 concurrency=100 | ... ==> "10.0.0.1" is an invalid concurrency channel number. Channel IDs are integer values in current helpers. If your squid.conf contains "concurrency=100" the channel-ID delivered to the helper will be an integer between 0 and 99 (inclusive). ==> "concurrency=100" is the name of the session you just asked the helper to create. ==> combined the above problems mean your helper test is not testing the same type of sessions as your other tests are trying to use. Luckily the session helper does not actually care what the session name values are, they are just opaque strings - hashed and stored for "-t N" seconds. So this still tests that the helper works, just not in the way apparently intended. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users