Re: [squid-users] Trying to implement Portal Splash

From: Jim Moseby <>
Date: Mon, 15 Nov 2010 09:37:11 -0500

>>> On 11/13/2010 at 12:20 AM, in message <>, Amos
Jeffries <> wrote:
> > This seems a bit ambiguous for people who are new to squid (like me).
> > I have tried pasting the block of code in various places in my config
> > file, and it seems no matter where I put it, I get the same result
> > from IE: "The page cannot not displayed, Diagnose Connection
> > Problems".
> Your config should have the http_access rules broken into three labeled
> sections.
> One labeled "Recommended minimum configuration" has the basic security
> settings.
> CLIENTS" ... as it says.
> and One labeled "And finally deny all other access to this proxy"
> You can do almost anything you like in the middle section without
> causing too much damage. Altering the others needs a bit of care.

Makes sense. Thanks for the clarification :)

> >
> > #----- SQUID 2.6.STABLE14 -----#
> <snip>
> >
> > #splash
> > external_acl_type session ttl=60 %SRC /usr/lib/squid/squid_session -t 7200
> -b /etc/squid/session.db
> > acl new_users external session
> > deny_info http://proxy.efa.lan/aup.php new_users
> > http_access deny !new_users
> >
> > http_access allow auth
> > http_access deny all
> >
> <snip all the safety controls, which have been placed after "deny all">
> Strange. This should be working. It is almost exactly the config I have
> in action at several wifi POPs which that page was written about.
> * Check that the /etc/squid/session.db file permissions are open for the
> squid effective user to read/write.

"AHA!" I thought. There was no /etc/squid/session.db file! "Stupid mistake, easy fix." I muttered. I did a 'touch /etc/squid/session.db' followed by a 'chmod 777 /etc/squid/session.db'. Restart squid......and......... no joy. Same thing happens. :(

After rereading my original post, I failed to mention that I am using squid in conjunction with dansguardian. Could this be a DG problem?

> * Give it a try with a browser other than IE. They have diagnosis
> tools which can show you which part of the transaction is failing and
> details (firebug add-on for firefox or any of the webkit based browsers
> have it built in).
> What you should expect to see there is a GET request for page, reply
> of 302 status and followup GET request for your deny_info URL.

If I try it with Firefox, I get prompted to DOWNLOAD the php splash page. If I change the configuration to use an HTML page instead, I just get a blank page.

I'll try to get firebug installed and see what is happening behind the curtain.


Received on Mon Nov 15 2010 - 14:37:49 MST

This archive was generated by hypermail 2.2.0 : Tue Nov 16 2010 - 12:00:03 MST