Superkorrekt ist, dass die WLAN-Betreiber vor dem Einloggen bzw. der Zustimmung zu den AG und Datenschutzerklärung jeden HTTP-Request (**Nicht: HTTPS!**) per Firewall-Regel umleiten und alle anderen Protokolle ~~womöglich~~ blockieren. Die Browser gehen (weil, es sonst Probleme mit https-Requests gibt) aber soweit, nach einem Start einen Hintergrund-Request auf eine Seite durchzuführen. Das wären * http://www.**microsoftconnecttest.com**:80/connecttest.txt oder * http://**www.msftncsi.com**:80/ncsi.txt * http://**detectportal.firefox.com**/canonical.html oder * http://**clients3.google.com**/generate_204 * http://**connectivitycheck.gstatic.com**/generate_204 Ist die Antwort nicht die erwartete, wird (wie auch immer) vom Browser der Hinweis angezeigt, dass man sich beim Netzbetreiber anmelden möge (oder der Wunsch nach einer solchen Benachrichtigung (z.B. via OSD) dem OS übermittelt.) Der Klick oder Tipp auf den Hinweis führt dann zu einer der Seiten, aber da der Request auf alle HTTP-Ressourcen vom WLAN-Anbieter erst einmal via Status-Code `302 FOUND` oder `303 SEE OTHER` umgeleitet wird bekommt man dann automatisch die korrekte Anmeldeseite des Betreibers zu sehen. **Datenschutz: Tipp für diejenigen, die wissen was sie tun:** Auch nicht-mobilen-Rechnern die Hostnamen mittels Host-Datei (oder, wie ich zu Hause mittels eigenem DNS ) durch die Angabe der IP 0.0.0.0 blockieren oder (mobile Rechner) dem localhost bzw. einem eigenem lokalem Server zuweisen und via Webserver also selbst die erwartete Antwort senden. Ich glaube sogar, dass dann der Browser-Start schneller geht… **Aber (Achtung):** Macht man dabei was falsch, kommt man im ICE oder Hotel, … nicht mehr ins WLAN... **Literatur:** <https://de.wikipedia.org/wiki/Captive_Portal>

Superkorrekt ist, dass die WLAN-Betreiber vor dem Einloggen bzw. der Zustimmung zu den AG und Datenschutzerklärung jeden HTTP-Request (**Nicht: HTTPS!**) per Firewall-Regel umleiten und alle anderen Protokolle ~~womöglich~~ blockieren. Die Browser gehen (weil, es sonst Probleme mit https-Requests gibt) aber soweit, nach einem Start einen Hintergrund-Request auf eine Seite durchzuführen. Das wären * http://www.**microsoftconnecttest.com**:80/connecttest.txt oder * http://**www.msftncsi.com**:80/ncsi.txt * http://**detectportal.firefox.com**/canonical.html oder * http://**clients3.google.com**/generate_204 * http://**connectivitycheck.gstatic.com**/generate_204 Ist die Antwort nicht die erwartete, wird (wie auch immer) vom Browser der Hinweis angezeigt, dass man sich beim Netzbetreiber anmelden möge (oder der Wunsch nach einer solchen Benachrichtigung (z.B. via OSD) dem OS übermittelt.) Der Klick oder Tipp auf den Hinweis führt dann zu einer der Seiten, aber da der Request auf alle HTTP-Ressourcen vom WLAN-Anbieter erst einmal via Status-Code `302 FOUND` oder `303 SEE OTHER` umgeleitet wird bekommt man dann automatisch die korrekte Anmeldeseite des Betreibers zu sehen. **Datenschutz: Tipp für diejenigen, die wissen was sie tun:** Auch nicht-mobilen-Rechnern die Hostnamen mittels Host-Datei (oder, wie ich zu Hause mittels eigenem DNS ) durch die Angabe der IP 0.0.0.0 blockieren oder (mobile Rechner) dem localhost bzw. einem eigenem lokalem Server zuweisen und via Webserver also selbst die erwartete Antwort senden. Ich glaube sogar, dass dann der Browser-Start schneller geht… **Aber (Achtung):** Macht man dabei was falsch, kommt man im ICE oder Hotel, … nicht mehr ins WLAN... **Literatur:** <https://de.wikipedia.org/wiki/Captive_Portal>

Superkorrekt ist, dass die WLAN-Betreiber vor dem Einloggen bzw. der Zustimmung zu den AG und Datenschutzerklärung jeden HTTP-Request (**Nicht: HTTPS!**) per Firewall-Regel umleiten und alle anderen Protokolle ~~womöglich~~ blockieren. Die Browser gehen (weil, es sonst Probleme mit https-Requests gibt) aber soweit, nach einem Start einen Hintergrund-Request auf eine Seite durchzuführen. Das wären * http://www.**microsoftconnecttest.com**:80/connecttest.txt oder * http://**www.msftncsi.com**:80/ncsi.txt * http://**detectportal.firefox.com**/canonical.html oder * http://**clients3.google.com**/generate_204 * http://**connectivitycheck.gstatic.com**/generate_204 Ist die Antwort nicht die erwartete, wird (wie auch immer) vom Browser der Hinweis angezeigt, dass man sich beim Netzbetreiber anmelden möge (oder der Wunsch nach einer solchen Benachrichtigung (z.B. via OSD) dem OS übermittelt.) Der Klick oder Tipp auf den Hinweis führt dann zu einer der Seiten, aber da der Request auf alle HTTP-Ressourcen vom WLAN-Anbieter erst einmal via Status-Code `302 FOUND` oder `303 SEE OTHER` umgeleitet wird bekommt man dann automatisch die korrekte Anmeldeseite des Betreibers zu sehen. **Datenschutz: Tipp für diejenigen, die wissen was sie tun:** Auch nicht-mobilen-Rechnern die Hostnamen mittels Host-Datei durch die Angabe der IP 0.0.0.0 blockieren oder (mobile Rechner) dem localhost bzw. einem eigenem lokalem Server zuweisen und via Webserver also selbst die erwartete Antwort senden. Ich glaube sogar, dass dann der Browser-Start schneller geht… **Literatur:** <https://de.wikipedia.org/wiki/Captive_Portal>

Superkorrekt ist, dass die WLAN-Betreiber vor dem Einloggen bzw. der Zustimmung zu den AG und Datenschutzerklärung jeden HTTP-Request (**Nicht: HTTPS!**) per Firewall-Regel umleiten und alle anderen Protokolle ~~womöglich~~ blockieren. Die Browser gehen (weil, es sonst Probleme mit https-Requests gibt) aber soweit, nach einem Start einen Hintergrund-Request auf eine Seite durchzuführen. Das wären * http://www.**microsoftconnecttest.com**:80/connecttest.txt oder * http://**www.msftncsi.com**:80/ncsi.txt * http://**detectportal.firefox.com**/canonical.html oder * http://**clients3.google.com**/generate_204 * http://**connectivitycheck.gstatic.com**/generate_204 Ist die Antwort nicht die erwartete, wird (wie auch immer) vom Browser der Hinweis angezeigt, dass man sich beim Netzbetreiber anmelden möge (oder der Wunsch nach einer solchen Benachrichtigung (z.B. via OSD) dem OS übermittelt.) Der Klick oder Tipp auf den Hinweis führt dann zu einer der Seiten, aber da der Request auf alle HTTP-Ressourcen vom WLAN-Anbieter erst einmal via Status-Code `302 FOUND` oder `303 SEE OTHER` umgeleitet wird bekommt man dann automatisch die korrekte Anmeldeseite. **Datenschutz: Tipp für diejenigen, die wissen was sie tun:** Die Hostnamen mittels Host-Datei blockieren oder dem localhost bzw. einem eigenem lokalem Server zuweisen und via Webserver also selbst die erwartete Antwort senden. **Literatur:** <https://de.wikipedia.org/wiki/Captive_Portal>

Superkorrekt ist, dass die WLAN-Betreiber vor dem Einloggen bzw. der Zustimmung zu den AG und Datenschutzerklärung jeden HTTP-Request (**Nicht: HTTPS!**) per Firewall-Regel umleiten und alle anderen Protokolle ~~womöglich~~ blockieren. Die Browser gehen (weil, es sonst Probleme mit https-Requests gibt) aber soweit, nach einem Start einen Hintergrund-Request auf eine Seite durchzuführen. Das wären * http://www.**microsoftconnecttest.com**:80/connecttest.txt oder * http://**www.msftncsi.com**:80/ncsi.txt * http://**detectportal.firefox.com**/canonical.html oder * http://**clients3.google.com**/generate_204 * http://**connectivitycheck.gstatic.com**/generate_204 Ist die Antwort nicht die erwartete, wird (wie auch immer) vom Browser der Hinweis angezeigt, dass man sich beim Netzbetreiber anmelden möge (oder der Wunsch nach einer solchen Benachrichtigung (z.B. via OSD) dem OS übermittelt.) Der Klick oder Tipp auf den Hinweis führt dann zu einer der Seiten, aber da der Request auf alle HTTP-Ressourcen vom WLAN-Anbieter erst einmal via Status-Code `302 FOUND` oder `303 SEE OTHER` umgeleitet wird bekommt man dann automatisch die korrekte Anmeldeseite. **Datenschutz: Tipp für diejenigen, die wissen was sie tun:** Die Hostnamen mittels Host-Datei blockieren oder dem localhost bzw. einem eigenem lokalem Server zuweisen und via Webserver also selbst die erwartete Antwort senden. Literatur: <https://de.wikipedia.org/wiki/Captive_Portal>

Superkorrekt ist, dass die WLAN-Betreiber vor dem Einloggen bzw. der Zustimmung zu den AG und Datenschutzerklärung jeden HTTP-Request (**Nicht: HTTPS!**) per Firewall-Regel umleiten und alle anderen Protokolle ~~womöglich~~ blockieren. Die Browser gehen (weil, es sonst Probleme mit https-Requests gibt) aber soweit, nach einem Start einen Hintergrund-Request auf eine Seite durchzuführen. Das wären * http://www.**microsoftconnecttest.com**:80/connecttest.txt oder * http://**www.msftncsi.com**:80/ncsi.txt * http://**detectportal.firefox.com**/canonical.html oder * http://**clients3.google.com**/generate_204 * http://**connectivitycheck.gstatic.com**/generate_204 Ist die Antwort nicht die erwartete, wird (wie auch immer) vom Browser der Hinweis angezeigt, dass man sich beim Netzbetreiber anmelden möge (oder der Wunsch nach einer solchen Benachrichtigung (z.B. via OSD) dem OS übermittelt.) Der Klick oder Tipp auf den Hinweis führt dann zu einer der Seiten, aber da der Request auf alle HTTP-Ressourcen vom WLAN-Anbieter erst einmal via (Status-Code `302 FOUND`) oder `303 SEE OTHER`) umgeleitet wird bekommt man dann automatisch die korrekte Anmeldeseite. **Datenschutz: Tipp für diejenigen, die wissen was sie tun:** Die Hostnamen mittels Host-Datei blockieren oder dem localhost bzw. einem eigenem lokalem Server zuweisen und via Webserver also selbst die erwartete Antwort senden. Literatur: <https://de.wikipedia.org/wiki/Captive_Portal>