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
