[squid-users] splash page: redirection loop

Mon Jun 24 22:59:03 UTC 2019

 Thanks Amos!
Comments inline
    On Monday, June 24, 2019, 9:06:41 a.m. EDT, Amos Jeffries <squid3 at treenet.co.nz> wrote:  

 On 24/06/19 5:04 am, julien412 at yahoo.fr 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.

[J] Agreed. this line is commented to allow testing from localhost with splash page: `http_access allow localhost`

* 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.
[J] It does not. I tested on private environment with different systems and src-IP stays the same as expected.

 - 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.
[J] I don't see any test on access.log. travis after_script includes access.log for convenience and missing access_custom.log which is the one relevant here. no serverspec tests

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

[J] tried both line below but does not seem to work`external_acl_type splash_page ttl=60 concurrency=100 %SRC /usr/lib/squid/ext_session_acl -t 7200 -b /var/lib/squid/session.db -d``external_acl_type splash_page ttl=60 concurrency=100 %SRC /usr/lib/squid/ext_session_acl -d -t 7200 -b /var/lib/squid/session.db`=> from cache.log
2019/06/24 14:03:01 kid1| helperOpenServers: Starting 1/5 'ext_session_acl' processes
(ext_session_acl): invalid option -- 'd'
Usage: (ext_session_acl) [-t|-T session_timeout] [-b dbpath] [-a]
        -t sessiontimeout       Idle timeout after which sessions will be forgotten (user activity will reset)
        -T sessiontimeout       Fixed timeout after which sessions will be forgotten (regardless of user activity)
        -b dbpath               Path where persistent session database will be kept
        -a                      Active mode requiring LOGIN argument to start a session

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.
[J] so, should be just an integer like that?
  describe command('echo 42 concurrency=100 | ...
[J] concurrency was just to avoid this# echo 10 | /usr/lib/squid/ext_session_acl -t 7200 -b /var/lib/squid/session.db
FATAL: /usr/lib/squid/ext_session_acl is concurrent and requires the concurrency option to be specified.[J] so the right test would be? both seems to work.
  describe command('echo 42 test concurrency=100 | ...or
  describe command('echo 42 test | ...

Amos
_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20190624/ad6fddc7/attachment-0001.html>