Wyskakujące okienka portalu: ostateczny przewodnik [zamknięty]

Ręcznie wdrażam portal dla niewoli WiFi. Mam prawie wszystko działające, ALE za jednym razem: chcę, aby wszyscy widzieli wyskakujące okienko portalu mobilnego systemu operacyjnego (lub komputerowego), aby zapewnić bezproblemowe wrażenia.

Ponieważ każdy z nich ma swój własny zakręcony sposób, wydaje się, że nie jestem w stanie uzyskać spójnego doświadczenia na różnych platformach.

Aby tak się stało, czy mogę pomóc w opisaniu (1), jakie żądania URL od klientów Wi-Fi muszą zostać przekierowane na stronę logowania i / lub (2) jakiej konfiguracji serwera WWW nginx lub apache można użyć do przekierowania Wi-Fi klienci do strony logowania?

Moja strona logowania do portalu typu captive w tym przykładzie to http: //captiveportal.lan . Oto niektóre systemy operacyjne, dla których próbuję rozwiązać ten problem.

Android 4/5/6

• Apache:
  RedirectMatch 302 /generate_204 http://captiveportal.lan
  
• nginx:?
  

Poprzednie wersje Androida

• Apache:?
  
• nginx:?
  

iOS 8

• Apache .htaccess:
  RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} ^CaptiveNetworkSupport(.*)$ [NC]
RewriteRule ^(.*)$ http://captiveportal.lan [L,R=302]
  

• nginx:?
  

Poprzednie wersje iOS

• Apache:?
  
• nginx:?
  

Telefon Windows

• Apache:
  RedirectMatch 302 /ncsi.txt http://captiveportal.lan
  
• nginx:?

Windows 7 \ 8 \ 10

• Apache: patrz Windows Phone (działa na Win7).
• nginx:?
  

System operacyjny Mac

• Apache:?
  
• nginx:?
  

Amazon Kindle - czy ma wyskakujące okienko?

• Apache:?
  
• nginx:?
  

Wszystkie mobilne systemy operacyjne po prostu sprawdzają stronę internetową, aby zdecydować, czy stoją za portalem dla niewolników, czy nie.

Mechanizm jest następujący:

1. GET / POST http://foo.com/bar.html
2. Jeśli bar.html == [oczekiwana treść]> Otwórz Internet
3. Jeśli bar.html! = [Oczekiwana treść]> Captive Portal
4. Jeśli bar.html [status]! = SUKCES> Brak sieci

Ponadto w przypadku systemu iOS musisz mieć domenę dla swojej sieci Wi-Fi, ponieważ zakłada ona, że ​​sieć bezdomenowa bez dostępu jest siecią domową i oznacza ją jako Brak sieci zamiast Captive Portal.

Pamiętaj tylko o wyraźnym przekierowaniu następujących adresów URL do portalu dostępowego za pomocą HTTP Success:

Android / Chromebook:

• klienci3.google.com

iOS 6:

• gsp1.apple.com
• * .akamaitechnologies.com

iOS 7:

• www.appleiphonecell.com
• www.airport.us
• * .apple.com.edgekey.net
• * .akamaiedge.net
• * .akamaitechnologies.com

iOS 8/9:

• http://www.apple.com/library/test/success.html
• http://captive.apple.com/hotspot-detect.html

Windows

• ipv6.msftncsi.com
• www.msftncsi.com

Wielu dostawców zaczęło również używać agenta użytkownika „CaptiveNetworkSupport”, choć nie jest to tak powszechne jak powyższa metoda adresu URL. Po prostu sprawdź ten UA i zawsze daj mu swoją stronę portalu ... nie działa jednak w 100%.

Używam metody URL i działa dobrze.

Amazon Kindle (Fire)

Amazon Kindle (Fire) wysyła następujące żądanie, a jeśli nie można go odzyskać „... zakłada, że ​​użytkownik musi się zalogować i wyświetla ekran logowania.”:

• http://spectrum.s3.amazonaws.com/kindle-wifi/wifistub.html
  • Zobacz także: https://forums.developer.amazon.com/forums/thread.jspa?threadID=834

iOS 8.4

W przypadku najnowszego iOS musiałem dopasować wszystkie identyfikatory URI dla żądań do http://captive.apple.com - nie tylko „/hotspot-detect.html”.

Klienci systemu iOS 8.4 przesyłają żądania z losowo generowanymi identyfikatorami URI (np. „/xmqPyZUv/3r8jTjv8.html” i „/7exN0TV7q0COX0/eKlBU8baU2tape/fjXUzDHBdE6W0O/BGbw7iYU2DVBht_tv).

• http://captive.apple.com
• http://www.ibook.info
• http://www.itools.info
• http://www.thinkdifferent.us