Re: WiFi - login page redirection not working

[Vincent Bernat <bernat () luffy cx>]

 ❦ 30 novembre 2017 18:26 -0800, Owen DeLong <owen () delong com> :

> > SSL requests are.  For example, Google cache's their 301 redirect
> > from http://www.google.com <http://www.google.com/> to
> > https://www.google.com <https://www.google.com/> which means clients
> > that had access while that browser ps stays active will still
> > attempt https instead of http, regardless of what you actually type.
>
> Right, you’re talking about HSTS as I mentioned below.
>
> However, if there’s a well known URL for getting the captive portal to
> work (e.g. http://captive.portal), then we educate users (or
> browsers that they can type captive.portal (or whatever URL we choose)
> instead of google (which was my traditional go to before HSTS,
> I admit) and voila… Problem solved.

You can use http://neverssl.com/.

But as mentioned earlier in the discussion, most OS have a non-HTTPS URL
to detect a captive portal. They can display notifications to the user
when they detect a captive portal. Browsers have that too.

iOS/macOS: http://captive.apple.com/hotspot-detect.html
Windows: http://www.msftncsi.com/ncsi.txt
Ubuntu: http://start.ubuntu.com/connectivity-check
Firefox: http://detectportal.firefox.com/
Chromium: http://clients3.google.com/generate_204

DHCP and neighbor discovery can also provide the information of the
login page: https://tools.ietf.org/html/rfc7710
-- 
After all, all he did was string together a lot of old, well-known quotations.
                -- H. L. Mencken, on Shakespeare