Pop-ups do portal cativo: o guia definitivo [fechado]

Estou implementando manualmente um portal cativo de WiFi. Eu tenho tudo praticamente funcionando, exceto um único problema: quero que todos vejam o pop-up cativo do portal de seus SOs móveis (ou SOs de computador) para uma experiência impecável.

Como cada um deles tem sua própria maneira distorcida de fazer isso, eu aparentemente não consigo obter uma experiência consistente entre plataformas.

Para que isso aconteça, posso ter ajuda para descrever (1) quais solicitações de URL de clientes WiFi precisam ser redirecionadas para uma página de login e / ou (2) qual configuração de servidor da web nginx ou apache pode ser usada para redirecionar a rede WiFi clientes para uma página de login?

Minha página de login do portal cativo neste exemplo é http: //captiveportal.lan . Aqui estão alguns dos sistemas operacionais para os quais estou tentando resolver isso.

Android 4/5/6

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

Versões anteriores do Android

• Apache:?
  
• nginx:?
  

iOS 8

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

• nginx:?
  

Versões anteriores do iOS

• Apache:?
  
• nginx:?
  

Telefone do Windows

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

Windows 7 \ 8 \ 10

• Apache: veja windows phone (funciona em win7).
• nginx:?
  

Mac OS

• Apache:?
  
• nginx:?
  

Amazon Kindle - ele tem um pop-up?

• Apache:?
  
• nginx:?
  

Todo sistema operacional móvel apenas verifica uma página da web para decidir se está ou não atrás de um portal cativo.

O mecanismo é este:

1. GET / POST http://foo.com/bar.html
2. Se bar.html == [conteúdo esperado]> Internet aberta
3. If bar.html! = [Conteúdo esperado]> Portal Cativo
4. Se bar.html [status]! = SUCESSO> Sem rede

Além disso, para iOS, você precisa ter um domínio para sua rede Wi-Fi, pois assume que uma rede sem domínio sem acesso é uma rede doméstica e apenas a marca como Sem Rede em vez de Portal Cativo.

Apenas certifique-se de redirecionar explicitamente os seguintes URLs para o seu portal cativo com o HTTP Success:

Android / Chromebook:

• clients3.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

janelas

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

Muitos fornecedores também começaram a usar o Agente do usuário "CaptiveNetworkSupport", embora não seja tão comum quanto o método de URL acima. Basta verificar esse UA e sempre fornecer sua página de portal ... embora não funcione 100%.

Eu uso o método URL e ele está funcionando bem.

Amazon Kindle (Fire)

O Amazon Kindle (Fire) faz a seguinte solicitação e, se não puder ser recuperado "... assume que o usuário precisa fazer login e exibe uma tela de Logon".

• http://spectrum.s3.amazonaws.com/kindle-wifi/wifistub.html
  • Consulte também: https://forums.developer.amazon.com/forums/thread.jspa?threadID=834

iOS 8.4

Para o iOS mais recente, eu tive que corresponder a todos os URIs para solicitações de http://captive.apple.com - não apenas "/hotspot-detect.html".

Os clientes do iOS 8.4 estão fazendo solicitações com URIs gerados aleatoriamente (por exemplo, "/xmqPyZUv/3r8jTjv8.html" e "/7exN0TV7q0COX0/eKlBU8baU2tape/fjXUzDHBdE6W0O/BGbw7iYU2DVTml", no seguinte portal:

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