3 ms·
Too bad there is no standard that is used to prevent these workarounds.
by stop50 4y ago
Too bad there is no standard that is used to prevent these workarounds.
- CGamesPlay 4y agoIndeed. This should really be the responsibility of the Wifi stack, which imposes the restriction and sits on a lower level than the HTTP stack. My gopher connections never work when I am behind a captive portal!
- stop50 4y agoThere is the standard 8952. But it nowhere implemented yet. it uses https, dhcp and ra to give the client the captive portal information.
- captivehacker1 4y agoIt is though. I've implemented a captive portal that uses this successfully for sending modern mobile OS like Android and iOs through captive portal. Marcos works fine too, also newer windows.
- LtWorf 4y agoMany of those networks block most ports except http, https basically.
- wichert 4y agoThe WISPr[0] standard was created for this purpose, and is (or was by now?) used by companies such as iPass to their customers to transparently log in to most WiFi hotspots. I don't think that standard is accessibly anywhere these days. I made a Python implementation [1] that should still work. [0] https://en.wikipedia.org/wiki/WISPr https://en.wikipedia.org/wiki/WISPr [1] https://github.com/wichert/wispr https://github.com/wichert/wispr
- lukeboi 4y agoThere is a dhcp option that can be used as an alternative that was recently (~2yr ago) introduced but it’s not supported by any major OSes except android
- captivehacker1 4y agoIt took some time to adopt, but works at least on recent mobile OS and MacOS.
- stop50 4y agoThere is rfc 8952, but its not official yet. Including the others which are referenced. The dhcp option is also not official yet.