On 24/06/19 5:04 am, julien...@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.
* 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@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
