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

Question

Estou implementando manualmente um portal cativo de Wi-Fi. Eu tenho tudo muito bem trabalhando, mas um único problema: eu quero que todos vejam o pop-up do portal cativo de seus sistemas operacionais móveis (ou sistemas operacionais de computador) para uma experiência perfeita.

Como cada um deles tem sua própria forma distorcida de fazê-lo, parece que não consigo ter uma experiência consistente em várias plataformas.

Para que isso aconteça, posso obter alguma 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 do servidor web nginx ou apache pode ser usada redirecionar os clientes WiFi para uma página de login?

Minha página de login do portal cativo neste exemplo é link . Aqui estão alguns dos sistemas operacionais que 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 em RewriteCond %{HTTP_USER_AGENT} ^CaptiveNetworkSupport(.*)$ [NC] em RewriteRule ^(.*)$ http://captiveportal.lan [L,R=302] em

• nginx:?
  

Versões anteriores do iOS

• Apache:?
  
• nginx:?
  

Windows phone

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

Windows 7 \ 8 \ 10

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

Mac OS

• Apache:?
  
• nginx:?
  

Amazon Kindle - ele tem um pop-up?

• Apache:?
  
• nginx:?
  

Answer 1

Todo sistema operacional para dispositivos móveis apenas verifica uma página da web para decidir se ela está ou não por trás de um portal cativo.

O mecanismo é este:

1. GET / POST link
2. Se bar.html == [conteúdo esperado] > Internet aberta
3. Se bar.html! = [conteúdo esperado] > Portal cativo
4. Se bar.html [status]! = SUCESSO > Nenhuma rede

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

Apenas certifique-se de redirecionar explicitamente os URLs a seguir para seu portal cativo com sucesso HTTP:

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:

• link
• link

Windows

• 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 dar a sua página de portal ... não funciona 100% embora.

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

    

Answer 2

Amazon Kindle (Fire)

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

• link
  • Veja também: link

iOS 8.4

Para o último iOS, tive que corresponder a todos os URIs para solicitações ao link - não apenas "/hotspot-detect.html".

Os clientes iOS 8.4 estão fazendo solicitações com URIs gerados aleatoriamente (por exemplo, "/xmqPyZUv/3r8jTjv8.html" e "/7exN0TV7q0COX0/eKlBU8baU2tape/fjXUzDHBdE6W0O/BGbw7iYU2DVBh1/sVBlx8icYzTTtE.html") em solicitações de URL para os seguintes domínios para detectar um cativo portal:

• link
• link
• link
• link