I like the straightforward explanation this site provides. That said, I tend to use <a href="http://example.com" rel="nofollow">http://example.com</a> to trigger captive portals because it's an IANA reserved domain [1] that other people can't register.<p>This gives me confidence to browse to it without fear that the domain could lapse in the future and get taken over (e.g. in a watering hole attack).<p>[1]: <a href="https://www.iana.org/domains/reserved" rel="nofollow">https://www.iana.org/domains/reserved</a>
My favorite version of this trend remains <a href="http://alwayshttp.com" rel="nofollow">http://alwayshttp.com</a> because <a href="https://alwayshttp.com" rel="nofollow">https://alwayshttp.com</a> doesn't work since alwayshttp.com:443 doesn't connect.<p>On the other hand, it's possible to reach <a href="https://coffeeshopwifi.com" rel="nofollow">https://coffeeshopwifi.com</a> and (with a cloudfront certificate error) <a href="https://neverssl.com" rel="nofollow">https://neverssl.com</a> which makes me wonder if something in whatever I'm using is trying to upgrade to HTTPS when I fail to reach them.
<a href="http://captive.apple.com/" rel="nofollow">http://captive.apple.com/</a> is pretty much always up because it has some pretty strong infrastructure behind it since billions of Apple devices connect to it automatically. It's always my goto for captive portals.
Seems like the DHCPACK message and/or router advertisement could/should have a reference to the URI that has policy/billing form that's required to utilize a gateway. That way we don't need a special magical service that expects to be redirected to the policy form. AFAICT each OS/distro seems to solve this their own way currently, with their own service.<p>Does any such standard feature already exist?
I use <a href="http://perdu.com/" rel="nofollow">http://perdu.com/</a><p>It says:<p><pre><code> Perdu sur l'Internet ?
Pas de panique, on va vous aider
* <----- vous êtes ici
</code></pre>
Translation:<p><pre><code> Lost on the Internet?
Don't panic, we are going to help you
* <----- you are here
</code></pre>
It is funny, it's been up and without change for decades (amazingly; first snapshot on archive.org in 1998, Wikipedia reports it's been there since 1996!), never had a https version, never noticed a downtime and I've yet to see a page that combine such a short / easy to type URL with such a short size (only 163 bytes, which is useful on spotty / weak connections).<p>Hard to beat.<p>CoffeeShopWifi.com is certainly a good idea, could be added to the favorites of non-technical English speakers. Coffee shops are not the only places with captive portal though, here in France they are common on Wifi access points provided by ISPs to their customers when they are roaming, and by the train company (SNCF) in trains and train stations.<p>Captive Portal is probably too technical so naming this is hard.
My go-to site for this is: <a href="http://pudim.com.br" rel="nofollow">http://pudim.com.br</a><p>Pudim is portuguese for pudding. This website runs for as long as I can remember and there is only low-res photograph of a pudding.
Neat to see all the alternatives. I'm not sure what non-technical folks do when faced with this problem, so I picked a friendly domain name.<p>Ironically, if CoffeeShopWifi.com works successfully, the users won't see it.
It seems that HTTPS is available which made my browser (in HTTPS-only mode) connect to the HTTPS site. I suppose that if HTTPS was blocked it would allow me to fall back to HTTP but it gives a much less clear error than something like <a href="http://neverssl.com/" rel="nofollow">http://neverssl.com/</a> does.
this doesn't explain why you should connect to the site or would need to use it. That first paragraph could describe the scenario.<p>As I haven't been <i>inside</i> a coffee shop or any public wifi scenario in over a year I was trying to remember what the use case was for this....
Yeah, captive portals are annoying. I got so frustrated with trying to connect to Starbucks' WiFi that I ended up writing my own script [1] that would allow me to authenticate from my terminal. I even wrote about what happens behind the scenes when you connect. [2]<p>1: <a href="https://github.com/imwally/coffeeconnect" rel="nofollow">https://github.com/imwally/coffeeconnect</a><p>2: <a href="https://nil.wallyjones.com/what-happens-when-you-connect-to-starbucks-wi-fi/" rel="nofollow">https://nil.wallyjones.com/what-happens-when-you-connect-to-...</a>
I don't understand how this (and other similar sites mentioned) work. What is going on with the network that makes visiting a non-SSL site make it work? Anyone care to offer an explanation or have a link to one?
I ctrl-f'd and didn't see anyone mention that you can look at your wifi settings, and visit the router aka default gateway IP to connect to the portal directly.<p>So like if your settings say your gateway is 192.168.0.1, go to <a href="https://192.168.0.1" rel="nofollow">https://192.168.0.1</a><p>This will work in situations where even a site like coffeeshopwifi.com doesn't
I used to use purple.com for this. Anyone who used it back in the golden age of the internet knows it was ideal for such purposes. It even had that squirrel game. Anyway after many many years of serving that masterpiece over plain http the guy sold the domain to some fucking matress company who insists on SSL.
My personal website (the top level index) is effectively a brochure with nothing that could be used for authenticating (there's a very broken javascript crypto app on it but that's just a toy and is clearly marked as such.) I always just use that.
Basically, <a href="http://clients1.google.com/generate_204" rel="nofollow">http://clients1.google.com/generate_204</a> with a more memorizable URL
> Coffee Shop Wifi always connects with HTTP instead of secure HTTPS. This allows guest wifi networks to show you their internet login page.<p>I always go to <a href="http://paulgraham.com" rel="nofollow">http://paulgraham.com</a> when I need to connect to guest WiFi for the exact same reason..