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

Hi Steve

I had no idea about WISPr or Apple’s support for it. Very cool. Just wanted to say thanks for all the details on it.

On 23 May 2014, at 8:22 pm, Steve Hill <steve_at_opendium.com> wrote:

> 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
Received on Fri May 23 2014 - 12:06:52 MDT