Início de sessão no portal cativo Android: Iniciar sessão e resolver falhas
Published
Está no átrio de um hotel, o seu telemóvel diz Conetado e nada carrega. Sem página de início de sessão, sem erro sobre o qual possa agir, apenas aplicações a carregar indefinidamente enquanto o ícone de WiFi exibe um pequeno aviso. É o início de sessão do portal cativo do Android a fazer mal o seu trabalho, ou a rede a responder às verificações do Android de uma forma que deixa o telemóvel bloqueado entre conetado e online.
A solução raramente passa por toques aleatórios no ecrã. O Android segue uma máquina de estados de deteção clara e, assim que souber em que estado se encontra, sabe em que tocar, que definição alterar ou se a falha é do próprio local. Eu começaria com o aviso do sistema e depois avançaria para o navegador, as definições de privacidade e só depois o design do portal em si.
Índice
- Iniciar sessão num portal cativo no Android em menos de um minuto
- Como o Android decide se uma rede requer início de sessão
- Corrigir falhas de início de sessão no seu próprio telemóvel
- Problemas conhecidos na deteção do portal cativo
- Dispositivos quiosque e geridos com Android
- Escolher um design de portal que funcione no Android
Iniciar sessão num portal cativo no Android em menos de um minuto
Procure a notificação Iniciar sessão na rede antes de abrir o Chrome. O Android abre-a na sua própria vista de início de sessão, regista as suas opções e volta a testar a rede quando terminar. Um separador de navegador que abra sozinho não tem qualquer um desses tratamentos, razão pela qual as pessoas que ignoram o aviso ficam frequentemente com uma página com sessão iniciada e um telemóvel que continua a insistir que não há internet.
- Toque na notificação Iniciar sessão na rede. Puxe a barra de notificações para baixo ou toque no aviso sob o nome da rede WiFi. Geralmente, este aparece poucos segundos após a ligação e encaminha-o diretamente para a página do local, sem ter de adivinhar um URL.
- Se não houver qualquer notificação, abra uma página http simples. No seu navegador, visite um endereço http e não https. O portal consegue intercetar e redirecionar um pedido simples, ao passo que uma página encriptada irá parar ou apresentar um aviso de certificado. Escolha um endereço que não tenha visitado recentemente, para que o navegador não responda a partir da sua memória cache e ignore a rede por completo.
- Conclua o passo do local. Aceite os termos, introduza o número do seu quarto, digite o código SMS ou utilize o login social disponibilizado. Não feche a janela antes do tempo, pois o Android precisa do sinal de conclusão para voltar a testar.
- Aguarde que o aviso desapareça. O ícone de WiFi deverá perder o triângulo de aviso e a indicação Sem internet deverá desaparecer. Essa alteração significa que o Android revalidou a ligação, e não apenas que carregou uma página - é essa a diferença entre uma sessão iniciada com sucesso e um formulário preenchido em vão.
- Desative e ative o WiFi uma vez se continuar a indicar Sem internet. Desligue e volte a ligar o WiFi antes de tentar qualquer ação mais invasiva. Uma nova ligação força uma nova verificação e limpa um resultado desatualizado.
O sucesso parece monótono, e esse é o objetivo. A notificação desaparece, a página pretendida carrega e as suas aplicações continuam a funcionar após sair do navegador. Se está a criar instruções repetíveis para funcionários ou convidados, coleções de guias passo a passo podem ajudá-lo a manter esses passos num formato que as pessoas sigam na receção.
Como o Android decide se uma rede requer início de sessão
Android não toma decisões a olhar para o seu navegador. Faz uma pergunta em segundo plano e, em seguida, avalia a resposta.
Quando o seu telemóvel se liga ao WiFi, envia um teste HTTP em texto simples para um endpoint de conetividade conhecido e aguarda uma resposta de sucesso vazia específica. Se a rede intercetar essa comunicação e retornar um redirecionamento ou uma página de início de sessão, o Android considera a rede como cativa e apresenta-lhe um aviso. A documentação do portal cativo do Android 11 refere que o Android introduziu a deteção integrada de portal cativo no Android 5.0, lançado em 2014, correspondente ao APInível 21, e que, historicamente, o teste utilizava o connectivitycheck.gstatic.com.
Essa data é importante para os operadores. A gestão do portal não é um truque de navegador que se adiciona à última hora. É uma função do sistema operativo que controla solicitações, etiquetas de validação e se as aplicações reconhecem que estão online.
Quem faz o quê no Android
O Android divide o trabalho. O NetworkMonitor testa a acessibilidade e o estado do portal. A aplicação pré-instalada de Login no portal cativo mostra a página de autenticação e comunica ao sistema a sua opção.
Depois de iniciar sessão, o Android repete o teste. Se a sondagem for bem-sucedida, a rede passa ao estado validado e o aviso desaparece. Se não passar, pode ter um formulário de autenticação preenchido e continuar sem acesso à internet.
O caminho mais recente é mais limpo. Uma rede pode anunciar o seu portal durante o DHCP utilizando a Opção DHCP 114, apontando o Android para um endpoint do Portal Cativo API. A Android referência NetworkCapabilities suporta a vertente da aplicação associada a este fluxo, onde o Android 11 e posterior pode obter esse endpoint durante o processamento do DHCP e uma resposta JSON com captive: true faz com que o Android apresente diretamente a interface de início de sessão do sistema. Se esse API não estiver disponível, o Android recorre a sondagens.
Para programadores de aplicações, o sinal está na resposta de chamada (callback) de rede. NET_CAPABILITY_CAPTIVE_PORTAL significa que a sondagem mais recente detetou um portal. NET_CAPABILITY_VALIDATED significa que a rede passou a validação.
Uma página HTTP 200 do portal não é prova de acesso à internet. Considere o início de sessão bem-sucedido apenas quando a rede atingir o estado validado.
Leitura da resposta da rede
| Resposta da rede | O que o Android conclui | O que você vê |
|---|---|---|
| HTTP 204 do endpoint do teste | A Internet está aberta, sem portal | Sem solicitação, a navegação funciona |
| HTTP 200 com HTML do portal em vez de 204 | Portal cativo detetado | Aviso de início de sessão apresentado |
| Teste bloqueado, tempo esgotado ou falha de DNS | A validação falhou, portal não identificado | Sem solicitação, aviso "Sem Internet" |
| JSON de portal cativo via DHCP Option 114 (Android 11 e posterior) | Início de sessão obrigatório | Página de início de sessão do sistema abre diretamente |
| O teste é aprovado após iniciar sessão | Rede validada | O aviso desaparece e as aplicações podem ligar-se |
Leia a tabela da esquerda para a direita. O Android não está a avaliar a sua identidade visual, os seus campos de formulário ou se a página parece concluída. Está a avaliar se a resposta da sondagem mudou conforme esperado antes da autenticação, e se regressa ao normal depois.
Imagine que um tablet de um hotel se liga à rede de convidados, mas nunca apresenta o aviso. A equipa culpa frequentemente a página de início de sessão e começa a redesenhar botões. Verifique primeiro o teste de sonda (probe), pois se a rede o bloquear, esgotar o tempo limite (timeout) ou o deixar passar demasiado livremente, o Android poderá nunca atingir o estado cativo que aciona o aviso.
Esse é o modelo mental a reter. A solicitação depende da forma como a rede responde a uma verificação automatizada. Um portal elegante não consegue corrigir uma resposta de sondagem incorreta, e uma resposta de sondagem correta pode fazer com que até um portal simples pareça fiável.
Corrigir falhas no início de sessão no seu próprio telefone
Analise os sintomas abaixo antes de alterar várias definições em simultâneo. Uma alteração, um novo teste e, só depois, avance.
| Sintoma | Causa provável | Solução |
|---|---|---|
| Sem notificação de início de sessão após ligar | Sonda bloqueada ou resultado antigo em cache | Esqueça a rede, volte a ligar-se e abra uma página http simples no navegador |
| A página de login só aparece em sites https | O portal apenas redireciona pedidos http simples | Abra uma página http para acionar o redirecionamento |
| Sessão iniciada, mas continua 'Sem internet' | DNS privado ou VPN a bloquear a verificação | Desative o DNS privado e a VPN, e depois reinicie o WiFi |
| O portal continua a reaparecer | O endereço MAC aleatório mudou para a sessão | Configure a rede para utilizar o endereço MAC do dispositivo nesta rede |
| A página de login está em branco ou não envia os dados | Cache do navegador desatualizada ou página do portal antiga | Limpe a cache do navegador e tente noutro navegador |
| Funciona num telemóvel, mas não noutro | Versão do Android ou definições de privacidade diferentes | Compare as versões do Android e teste com o MAC aleatório desativado |
| Ligado, mas as aplicações continuam a falhar | A conetividade ainda não foi revalidada | Aguarde 30 segundos e ative/desative o modo de avião |
Utilizaria esta ordem porque começa com a correção mais económica e evita enfraquecer a privacidade, a menos que seja estritamente necessário.
- Desative o WiFi, depois elimine a rede e volte a ligar-se. Isto limpa o resultado de validação em cache e força uma nova verificação.
- Verifique o DNS Privado, a VPN e o MAC aleatório. Estas definições estão diretamente no caminho do DNS, do encaminhamento e da identidade do dispositivo, pelo que são os próximos bloqueadores prováveis.
- Limpe a cache do navegador ou tente utilizar um segundo navegador. Faça isto quando a página estiver em branco, parcialmente carregada ou não submeter os dados.
Aviso de privacidade: Desativar o DNS Privado ou uma VPN reduz a sua proteção numa rede pública. Volte a ativar ambos assim que a autenticação for bem-sucedida, e não realize operações bancárias nem altere palavras-passe até o ter feito.
A linha do endereço MAC randomizado apanha muitas pessoas desprevenidas. Se o portal autorizou uma identidade MAC e o seu telemóvel apresenta outra na ligação seguinte, o local vê um novo dispositivo e exibe o portal novamente. Definir essa rede específica para utilizar o MAC do dispositivo estabiliza a sessão, mas não deve alterar isso globalmente para todas as redes.
Se nada disto funcionar, pare de repor definições. Anote a hora, o nome da rede e o modelo do dispositivo e, em seguida, forneça esses detalhes ao local para que possam verificar o lado do portal. Se o problema se estender para além do início de sessão do WiFi, pode encontrar ajuda para problemas no telemóvel referente a falhas mais amplas do dispositivo, mas um portal do local que nunca valida não será corrigido por uma reposição de fábrica.
Problemas conhecidos com a deteção do portal cativo
A solução instintiva do operador é permitir mais domínios antes do início de sessão. Esse instinto pode anular completamente o início de sessão no portal cativo do Android.
As orientações atuais da Captifi sobre portais cativos que não aparecem explicam que o Android executa verificações automáticas de conetividade que normalmente esperam uma resposta HTTP 204 de um ponto de extremidade de verificação de conetividade do Google e que, se um "walled garden" permitir esse ponto de extremidade de forma demasiado ampla, o Android pode concluir que existe acesso ilimitado à Internet e suprimir o pedido de início de sessão. Em termos simples, a sua lista de permissões pode convencer o telemóvel de que não existe qualquer portal.
Esse é o compromisso que os operadores ignoram. Uma lista de permissões restrita pode bloquear um script de pagamento ou fornecedor de identidade de que o portal necessita. Uma lista de permissões abrangente mantém a página visualmente apelativa, mas remove o gatilho que a abre.
Onde a máquina de estados falha
As falhas nem todas parecem um aviso em falta. As falhas de DNS podem deixar a validação pendente. Uma definição de VPN ou DNS privado pode contornar o resolvedor do local. O comportamento exclusivo de HTTPS não dá ao portal nada que este possa redirecionar em segurança. A randomização de MAC pode fazer com que um telemóvel pareça vários dispositivos em diferentes ligações.
Não é possível depurar esses casos a partir de uma captura de ecrã da página de início de sessão. Registe os sinais de sessão que mostram que estado o Android atingiu e onde parou.
- Resultado da sondagem: A verificação devolveu 204, um redirecionamento, HTML do portal ou nada?
- Resultado de DNS: O endpoint foi resolvido através do servidor de resolução do local?
- Estado do redirecionamento: O gateway enviou o dispositivo para o URL do portal?
- Erro no WebView: A vista de início de sessão falhou ao renderizar ou ao submeter?
- Identidade de MAC aleatório: Qual o endereço MAC que o portal autorizou?
- Validação pós-autenticação: A rede funcionou após a conclusão do formulário?
Suponha que os seus registos mostrem sondagens permitidas e uma autenticação bem-sucedida, mas a validação nunca acontece. Não culpe o dispositivo móvel em primeiro lugar. Verifique o redirecionamento pós-autenticação e a liberação de autorização, pois o portal pode ter aceite o formulário sem instruir a rede a libertar o dispositivo.
Faria quatro alterações, por esta ordem.
- Mantenha a lista de permissões pré-autenticação no mínimo necessário para o portal e os seus fornecedores de autenticação.
- Registe cada campo de telemetria acima para todas as sessões falhadas e com sucesso.
- Teste a integração segura por HTTPS para que os convidados não dependam de um único acionador http simples.
- Planeie um caminho sem portal para dispositivos que não devem depender de um portal, utilizando opções como OpenRoaming WiFi, Passpoint, ou certificados geridos.
Dispositivos Android em modo de quiosque e geridos
Um tablet gerido pode estar numa rede com redirecionamento correto e, ainda assim, nunca mostrar uma janela de início de sessão. Isso não é um problema de intensidade de sinal. Normalmente, é uma questão de política.
As recomendações ao consumidor pressupõem que pode tocar em notificações, desativar uma VPN e editar as definições de privacidade do WiFi. O utilizador de um quiosque raramente consegue fazer isso. As orientações de mobilidade empresarial sobre portais cativos em quiosques indicam que os portais cativos são geridos por uma aplicação pré-instalada e que a política do quiosque deve permiti-la explicitamente, pelo que um pacote de sistema de portal cativo bloqueado significa que o início de sessão nunca é iniciado, mesmo quando a rede funciona corretamente.
Isto afeta locais onde ninguém considera o dispositivo como sendo um telemóvel. Pense em tablets de hospitais e escolas, terminais portáteis de retalho, tablets de hotéis e ecrãs de check-in pertencentes aos estabelecimentos. O telemóvel pessoal do cliente inicia a sessão sem problemas, pelo que a equipa declara que a rede está a funcionar bem, enquanto a frota gerida permanece offline.
Suponha que um terminal de retalho funciona quando um gestor testa a mesma rede num telemóvel de funcionário, mas a imagem do quiosque permanece desligada. Verifique a lista de permissões da política antes de alterar o portal. O telemóvel prova que o redirecionamento existe. O terminal prova que a imagem gerida não o consegue abrir.
Execute as verificações de operador por esta ordem.
- Permita o pacote de sistema do portal cativo na sua política de EMM ou MDM, depois envie a política e volte a ligar o dispositivo de teste à rede.
- Testar o Android System WebView nessa imagem exata do dispositivo, porque um WebView desatualizado ou desativado pode fazer com que o portal fique em branco ou não consiga submeter os dados.
- Defina um caminho alternativo de integração para dispositivos que não conseguem apresentar um portal interativo, como um perfil pré-configurado ou uma adesão baseada em certificados, numa abordagem semelhante à integração de BYOD estruturada em vez de uma palavra-passe partilhada.
Política em primeiro lugar, WebView em segundo, alternativa em terceiro. Se inverter essa ordem, criará soluções de contorno para dispositivos que apenas precisavam de permissão para exibir a página Android já detetada.
Escolha um design de portal que funcione no Android
Comece com três critérios, não com o design da página de entrada. A frequência com que os convidados regressam, se os dispositivos são pessoais ou geridos, e quais as versões de Android que devem funcionar devem decidir o design.
Para convidados pontuais, um portal cativo continua a ser prático. Mantenha a lista de permissões pré-autenticação o mais reduzida possível, suporte os métodos de início de sessão esperados pelos utilizadores e certifique-se de que a libertação pós-início de sessão é suficientemente rápida para que o Android efetue a validação antes de o utilizador começar a alterar as definições. O nosso próprio portal pode ser adicionado a um controlador com o URL de landing page e o RADIUS em menos de 15 minutos, com opções de início de sessão que incluem o SSO, Google, Apple, Facebook e SMS, mas a rapidez de configuração não elimina a necessidade de testar o comportamento do teste.
Para visitantes recorrentes, recomendo que não force um portal em todas as visitas, se o puder evitar. O Passpoint ou OpenRoaming permite que um perfil instalado uma única vez se ligue automaticamente no regresso, sem o atrito do portal e sem formulários repetidos. Compare essa opção com a sua configuração atual quando analisar soluções de guest WiFiWiFi e confirme se o seu controlador e a configuração de RADIUS suportam a opção antes de se comprometer.
Depois, teste como um operador e não como um designer.
- Versão mais antiga do Android suportada: Confirme que o aviso aparece e que a validação é concluída.
- Dispositivo Android atual: Confirme que as predefinições de DNS privado e MAC randomizado não deixam o utilizador bloqueado.
- Build de quiosque gerido: Confirme que a política permite a aplicação do portal e que o WebView renderiza a página.
Em cada dispositivo, aguarde pelo estado validado e abra duas aplicações, e não apenas o navegador. Um telemóvel aprovado prova muito pouco, porque a deteção varia consoante a versão do Android, o suporte DHCP e a política do dispositivo. Faça a disponibilização aos convidados apenas quando os três forem aprovados.
Se os seus visitantes de Android continuam a deparar-se com um portal que não apresenta o pedido de acesso, não valida ou não mantém o início de sessão, o Purple Access pode ajudá-lo a disponibilizar um portal cativo personalizado para visitantes ocasionais e o Passpoint ou o OpenRoaming para dispositivos recorrentes nos pontos de acesso que já possui. Fale connosco para testar o seu dispositivo de Android mais antigo, os seus telemóveis atuais e qualquer estrutura de quiosque gerida antes da sua próxima implementação, garantindo que o início de sessão funciona à primeira.
