Re: [squid-users] Squid in a WiFi Captive portal scenario

On 14/05/14 20:02, JMangia wrote:

> Apple, Google, Microsoft implement a sort of automatic Web Popup page that
> appear just connecting to a WiFi network that implement a “captive portal”
> solution. This popup appear even if the internet request is not coming from
> the browser but also from any other App.
>
> On iOS / Mac Os for example once activated the WiFi the OS make an HTTP
> request for http://www.apple.com/library/test/success.html with special user
> agent CaptiveNetworkSupport/1.0 and to get the Splash Landing Page the
> captive solution must just not return Success.
>
> Microsoft implement something similar with WISPr support and Android try to
> contact http://clients3.google.com/generate_204 or
> http://www.google.com/blank.html.
>
> My squid configuration deny any destination and redirect to my landing
> splash page but the user need to open the browser to get this splash page.
> I mean if the user connect to wifi network and open any other App that use
> the connection no popup login page appear.
>
> Is there anyone else working in this scenario using Squid ?

iOS devices make a request to their servers as soon as they associate
with a wireless network. If the request doesn't return what they expect
then they assume its a captive portal login page and pop it up. They
also support WISPr - if the page has WISPr XML embedded in it then the
OS will scrape the user name and password from the POST request the
first time you log in and then automatically resubmit it in future
rather than popping up the page.

Old iOS devices used http://www.apple.com/library/test/success.html but
new versions of iOS probe a variety of URIs. If you return a login page
for any request, while the user isn't logged in, then it won't matter
which URI they use.

This works for me - Squid returns a 302 redirecting to a captive portal
login page which has embedded WISPr XML. The devices pop up the login
page the first time and thereafter use WISPr. Of course, the device
must be able to access that page when they're not logged in to the
proxy! This works for both transparent proxy connections and
non-transparent connections, but ISTR you *must* return a 302 - anything
else (such as a 200 with the login page itself, or a 407, will break).

I've not had too much experience with MS's devices so can't really comment.

HTC Android devices have supported WISPr for quite a while I believe,
but I don't think stock Android has support (or at least if it does it's
a pretty recent addition). The CoovaAX app will do WISPr on Android though.

Recent OS X versions also do WISPr iff they are using the wifi but not
for wired connections (which seems an odd distinction!)

Another gotcha is that the WISPr service must be https with a trusted
certificate, and ISTR the devices must be able to access the CA's
servers even before being authenticated in order to verify the
certificate. But I don't believe this affects the actual "pop up" login
screen, just WISPr automatic authentication.

-- 
 - Steve Hill
   Technical Director
   Opendium Limited     http://www.opendium.com
Direct contacts:
   Instant messager: xmpp:steve_at_opendium.com
   Email:            steve_at_opendium.com
   Phone:            sip:steve_at_opendium.com
Sales / enquiries contacts:
   Email:            sales_at_opendium.com
   Phone:            +44-844-9791439 / sip:sales_at_opendium.com
Support contacts:
   Email:            support_at_opendium.com
   Phone:            +44-844-4844916 / sip:support_at_opendium.com