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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx > Email: steve@xxxxxxxxxxxx > Phone: sip:steve@xxxxxxxxxxxx > > Sales / enquiries contacts: > Email: sales@xxxxxxxxxxxx > Phone: +44-844-9791439 / sip:sales@xxxxxxxxxxxx > > Support contacts: > Email: support@xxxxxxxxxxxx > Phone: +44-844-4844916 / sip:support@xxxxxxxxxxxx
