Login no portal cativo no Android: Faça login e resolva falhas
Published
Você está no saguão de um hotel, seu telefone diz Conectado e nada carrega. Nenhuma página de login, nenhum erro sobre o qual você possa agir, apenas aplicativos carregando infinitamente enquanto o ícone do WiFi exibe um pequeno aviso. Esse é o login do portal cativo do Android fazendo seu trabalho mal feito, ou a rede respondendo às verificações do Android de uma forma que deixa o telefone preso entre conectado e online.
A solução raramente é clicar aleatoriamente. O Android segue uma máquina de estados de detecção clara e, assim que você sabe em qual estado se encontra, sabe no que clicar, qual configuração alterar ou se a falha é do próprio local. Eu começaria com o aviso do sistema, avançando para o navegador, as configurações de privacidade e, só então, para o design do portal em si.
Sumário
- Faça login em um portal cativo no Android em menos de um minuto
- Como o Android decide se uma rede precisa de login
- Corrija falhas de login no seu próprio telefone
- Problemas conhecidos com a detecção de portal cativo
- Quiosques e dispositivos Android gerenciados
- Escolha um design de portal que funcione no Android
Faça login em um portal cativo no Android em menos de um minuto
Procure a notificação Fazer login na rede antes de abrir o Chrome. O Android a abre em sua própria visualização de login, rastreia o que você escolhe e testa a rede novamente quando você termina. Uma guia do navegador que você abre manualmente não recebe esse tratamento, e é por isso que as pessoas que ignoram o aviso geralmente terminam com uma página autenticada e um celular que ainda insiste que não há internet.
- Toque na notificação Fazer login na rede. Puxe para baixo a barra de notificações ou toque no aviso sob o nome da rede WiFi. Ela costuma aparecer alguns segundos após a conexão e leva você direto para a página do local sem precisar adivinhar a URL.
- Se não houver notificação, abra uma página http comum. Em seu navegador, acesse um endereço http, e não https. O portal consegue interceptar e redirecionar uma solicitação comum, enquanto uma página criptografada vai travar ou exibir um aviso de certificado. Escolha um endereço que você não tenha visitado recentemente para que o navegador não responda a partir do cache e ignore a rede completamente.
- Conclua a etapa do local. Aceite os termos, insira o número do seu quarto, digite o código recebido por SMS ou use o login social oferecido. Não feche a janela antes da hora, pois o Android precisa do sinal de conclusão para testar a conexão novamente.
- Aguarde o aviso desaparecer. O ícone de WiFi deve perder o triângulo de aviso e o rótulo Sem internet deve sumir. Essa alteração significa que o Android revalidou a conexão, e não apenas carregou uma página, sendo a diferença entre um login concluído e um formulário preenchido em vão.
- Reative o WiFi uma vez se ainda aparecer Sem internet. Desligue e ligue o WiFi antes de tentar algo mais invasivo. Uma nova conexão força uma verificação recente e limpa um resultado desatualizado.
O sucesso parece sem graça, e esse é o objetivo. A notificação desaparece, a página solicitada é carregada e seus aplicativos continuam funcionando depois que você sai do navegador. Se você estiver criando instruções repetíveis para a equipe ou convidados, coleções de guias passo a passo podem ajudar a manter essas etapas em um formato que as pessoas seguirão na recepção.
Como o Android decide se uma rede precisa de login
Android não decide olhando para o seu navegador. Ele faz uma pergunta em segundo plano e depois julga a resposta.
Quando seu telefone se conecta à WiFi, ele envia uma sonda HTTP em texto claro para um endpoint de conectividade conhecido e espera uma resposta de sucesso vazia específica. Se a rede interceptar essa solicitação e retornar um redirecionamento ou uma página de login, o Android tratará a rede como cativa e exibirá um aviso. A documentação de portal cativo do Android 11 observa que o Android introduziu a detecção nativa de portal cativo no Android 5.0, lançado em 2014, correspondente ao API nível 21, e que, historicamente, a sonda usava connectivitycheck.gstatic.com.
Essa data é importante para os operadores. O gerenciamento de portais não é um truque de navegador adicionado posteriormente. É uma função do sistema operacional que controla avisos, rótulos de validação e se os aplicativos acreditam que estão online.
Quem faz o que dentro do Android
O Android divide o trabalho. O NetworkMonitor testa a acessibilidade e o status do portal. O aplicativo de login do portal cativo pré-instalado exibe a página de autenticação e informa ao sistema o que você escolheu.
Depois de fazer login, o Android faz um novo teste. Se a verificação for aprovada agora, a rede passa para o status de validada e o aviso desaparece. Se não for aprovada, você pode ter um formulário de login preenchido e ainda assim não ter internet utilizável.
O caminho mais recente é mais limpo. Uma rede pode anunciar seu portal durante o DHCP usando a Opção 114 do DHCP, apontando Android para um endpoint de portal cativo API. A Android referência NetworkCapabilities é compatível com o lado do aplicativo relacionado desse fluxo, onde o Android 11 e posterior pode recuperar esse endpoint durante o processamento do DHCP e uma resposta JSON com captive: true faz com que o Android apresente a interface de login do sistema diretamente. Se esse API não estiver disponível, o Android recorre a testes de conectividade.
Para desenvolvedores de aplicativos, o sinal está no retorno de chamada da rede. NET_CAPABILITY_CAPTIVE_PORTAL significa que a verificação mais recente detectou um portal. NET_CAPABILITY_VALIDATED significa que a rede passou na validação.
Uma página HTTP 200 do portal não é prova de acesso à internet. Considere o login bem-sucedido apenas quando a rede atingir o status validado.
Lendo a resposta da rede
| Resposta da rede | O que o Android conclui | O que você vê |
|---|---|---|
| HTTP 204 do endpoint da sonda | 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 detectado | A notificação de login é exibida |
| Sonda bloqueada, tempo limite esgotado ou falha no DNS | A validação falhou, portal não identificado | Sem solicitação, rótulo "Sem internet" |
| JSON Cativo via Opção DHCP 114 (Android 11 e posterior) | Login necessário | A página de login do sistema é aberta diretamente |
| A sonda passa após você fazer login | Rede validada | O aviso desaparece e os aplicativos podem se conectar |
Leia a tabela da esquerda para a direita. O Android não está avaliando seu branding, seus campos de formulário ou se a página parece concluída. Ele está avaliando se a resposta da verificação mudou da maneira esperada antes do login e se ela volta ao normal depois.
Suponha que um tablet de hotel se conecte à rede de hóspedes, mas nunca exiba o aviso. A equipe costuma culpar a página de login e começar a redimensionar botões. Verifique o teste de conectividade primeiro, pois se a rede o bloquear, der tempo limite ou o permitir de forma muito livre, o Android pode nunca atingir o estado cativo que dispara o aviso.
Esse é o modelo mental que deve ser mantido. A exibição da mensagem depende de como a rede responde a uma verificação automatizada. Um portal aprimorado não consegue corrigir uma resposta de verificação incorreta, e uma resposta de verificação correta pode fazer até mesmo um portal simples parecer confiável.
Corrija falhas de login no seu próprio telefone
Análise os sintomas abaixo antes de alterar várias configurações de uma só vez. Uma alteração, um novo teste e depois avance.
| Sintoma | Causa provável | Solução |
|---|---|---|
| Sem notificação de login após conectar | Teste bloqueado ou resultado antigo em cache | Esqueça a rede, conecte-se novamente e abra uma página http comum no navegador |
| Página de login aparece apenas em sites https | Portal redireciona apenas solicitações http comuns | Abra uma página http para disparar o redirecionamento |
| Conectado, mas ainda exibe 'Sem internet' | DNS privado ou VPN bloqueando a verificação | Desative o DNS privado e a VPN e, em seguida, reative o WiFi |
| Portal continua reaparecendo | Endereço MAC aleatório alterado para a sessão | Configure a rede para usar o endereço MAC do dispositivo para esta rede |
| Página de login em branco ou não envia os dados | Cache do navegador desatualizado ou página do portal antiga | Limpe o cache do navegador e tente outro navegador |
| Funciona em um celular, mas não em outro | Versão diferente do Android ou configurações de privacidade | Compare as versões do Android e teste com o MAC aleatório desativado |
| Conectado, mas os aplicativos ainda falham | Conectividade ainda não revalidada | Aguarde 30 segundos e ative e desative o modo avião |
Eu usaria essa ordem porque ela começa com a solução mais barata e evita enfraquecer a privacidade, a menos que seja necessário.
- Alterne o WiFi, depois esqueça a rede e conecte-se novamente. Isso limpa o resultado de validação em cache e força uma nova sondagem.
- Verifique o DNS privado, a VPN e o MAC aleatório. Essas configurações estão diretamente no caminho do DNS, do roteamento e da identidade do dispositivo, portanto, são os próximos bloqueadores prováveis.
- Limpe o cache do navegador ou tente um segundo navegador. Faça isso quando a página estiver em branco, parcialmente carregada ou não for enviada.
Aviso de privacidade: Desativar o DNS privado ou uma VPN reduz sua proteção em uma rede pública. Reative ambos assim que o login for bem-sucedido e não faça operações bancárias nem alterações de senha até ter feito isso.
A linha de endereço MAC randomizado costuma pegar as pessoas de surpresa. Se o portal autorizou uma identidade MAC e seu celular apresenta outra na próxima conexão, o local vê um novo dispositivo e exibe o portal novamente. Configurar essa rede específica para usar o MAC do dispositivo estabiliza a sessão, mas você não deve alterar isso globalmente para todas as redes.
Se nada disso funcionar, pare de redefinir as configurações. Anote a hora, o nome da rede e o modelo do dispositivo e forneça esses detalhes ao local para que eles possam verificar o lado do portal. Se o problema se estender além do login do WiFi, você poderá encontrar ajuda com problemas no telefone cobrindo falhas mais amplas do dispositivo, mas um portal do local que nunca valida não será corrigido por uma redefinição de fábrica.
Problemas conhecidos com a detecção de portal cativo
A reação instintiva do operador é permitir mais domínios antes do login. Esse instinto pode quebrar completamente o login do portal cativo do Android.
As orientações atuais do Captifi sobre portais cativos que não aparecem explicam que o Android executa verificações automatizadas de conectividade que geralmente esperam uma resposta HTTP 204 de um ponto de extremidade de verificação de conectividade do Google. Se um jardim murado (walled garden) permitir esse ponto de extremidade de forma muito ampla, o Android poderá concluir que existe acesso ilimitado à internet e suprimir a solicitação de login. Em termos simples, sua lista de permissões pode convencer o telefone de que não há portal.
Esse é o ponto de equilíbrio que os operadores esquecem. Uma lista de permissões restrita pode bloquear um script de pagamento ou provedor de identidade de que o portal precisa. Uma lista de permissões ampla mantém a página bonita, mas remove o gatilho que a abre.
Onde a máquina de estados falha
Nem todas as falhas se parecem com um aviso ausente. Falhas de DNS podem deixar a validação suspensa. Uma configuração de VPN ou DNS Privado pode desviar do resolvedor do local. O comportamento exclusivo para HTTPS não fornece ao portal nada que ele possa redirecionar com segurança. A randomização de MAC pode fazer com que um celular pareça múltiplos dispositivos em diferentes conexões.
Você não consegue depurar esses casos a partir de uma captura de tela da página de login. Registre os sinais de sessão que mostram qual estado o Android atingiu e onde ele parou.
- Resultado do teste: A verificação retornou 204, um redirecionamento, o HTML do portal ou nada?
- Resultado do DNS: O endpoint foi resolvido pelo resolvedor do local?
- Status do redirecionamento: O gateway enviou o dispositivo para a URL do portal?
- Erro no WebView: A visualização de login falhou ao ser renderizada ou enviada?
- Identidade de MAC aleatório: Qual MAC o portal autorizou?
- Validação pós-autenticação: A rede funcionou após a conclusão do formulário?
Digamos que seus logs mostrem verificações permitidas e um login bem-sucedido, mas a validação nunca aconteça depois. Não culpe o aparelho de primeira. Verifique o redirecionamento pós-login e a liberação de autorização, pois o portal pode ter aceito o formulário sem avisar a rede para liberar o dispositivo.
Eu faria quatro alterações, nesta ordem.
- Mantenha a lista de permissões pré-autenticação no mínimo necessário para o portal e seus provedores de login.
- Registre cada campo de telemetria acima para todas as sessões com falha ou bem-sucedidas.
- Teste a integração segura por HTTPS para que os visitantes não dependam de um único acionador em HTTP comum.
- Planeje um caminho sem portal para dispositivos que não devem depender de um portal, usando opções como OpenRoaming WiFi, Passpoint, ou certificados gerenciados.
Dispositivos quiosque e gerenciados Android
Um tablet gerenciado pode estar em uma rede que redireciona corretamente e, ainda assim, nunca exibir uma janela de login. Isso não é um problema de intensidade de sinal. Geralmente é política.
As orientações para o consumidor presumem que você pode tocar em notificações, desativar uma VPN e alterar as configurações de privacidade do WiFi. O usuário de um quiosque geralmente não pode fazer nada disso. As orientações de mobilidade corporativa para portais cativos em quiosques afirmam que os portais cativos são gerenciados por um aplicativo pré-carregado e que a política do quiosque deve permiti-lo explicitamente. Portanto, um pacote de sistema de portal cativo bloqueado significa que o login nunca é iniciado, mesmo quando a rede funciona corretamente.
Isso prejudica locais onde ninguém pensa no dispositivo como um celular. Pense em tablets de hospitais e escolas, dispositivos portáteis de varejo, tablets de hotéis e telas de check-in pertencentes ao estabelecimento. O celular pessoal do visitante se conecta perfeitamente, então a equipe declara que a rede está funcionando bem enquanto a frota gerenciada permanece offline.
Digamos que um terminal portátil de varejo funcione quando um gerente testa a mesma rede no celular da empresa, mas a versão do quiosque continue desconectada. Verifique a lista de permissões de políticas antes de mexer no portal. O celular prova que o redirecionamento existe. O terminal portátil prova que a imagem gerenciada não vai abri-lo.
Execute as verificações do operador nesta ordem.
- Permita o pacote de sistema de portal cativo em sua política EMM ou MDM, envie a política para os dispositivos e conecte novamente à rede em um dispositivo de teste.
- Teste o Android System WebView exatamente nessa imagem de dispositivo, pois um WebView desatualizado ou desativado pode deixar o portal em branco ou impossibilitar o envio do formulário.
- Defina um caminho alternativo de integração para dispositivos que não conseguem exibir um portal interativo, como um perfil pré-configurado ou acesso baseado em certificado, semelhante em essência a uma integração estruturada de BYOD, em vez de uma senha compartilhada.
Política em primeiro lugar, WebView em segundo, fallback em terceiro. Se você inverter essa ordem, criará soluções alternativas para dispositivos que só precisavam de permissão para exibir a página Android já detectada.
Escolha um design de portal que funcione no Android
Comece com três critérios, não com o design da página de boas-vindas. A frequência com que os convidados retornam, se os dispositivos são pessoais ou gerenciados e quais versões do Android devem funcionar devem decidir o design.
Para visitantes ocasionais, um portal cativo ainda é prático. Mantenha a lista de permissões pré-autenticação o menor possível, ofereça suporte aos métodos de login esperados pelos visitantes e garanta que a liberação pós-login seja rápida o suficiente para que o Android faça a validação antes que o usuário comece a alterar as configurações. Nosso próprio portal pode ser adicionado a um controlador com o URL da splash page e o RADIUS em menos de 15 minutos, com opções de login incluindo SSO, Google, Apple, Facebook e SMS, mas a velocidade de configuração não elimina a necessidade de testar o comportamento da sonda.
Para visitantes recorrentes, recomendo não forçar um portal a cada visita, se puder evitar. O Passpoint ou OpenRoaming permite que um perfil instalado uma única vez se conecte automaticamente no retorno, sem o atrito do portal e sem formulários repetidos. Compare esse caminho com sua configuração atual ao revisar as soluções de WiFi para visitantes WiFi e confirme se a sua controladora e a configuração de RADIUS suportam a opção antes de se comprometer.
Em seguida, teste como um operador, não como um designer.
- Versão mais antiga do Android suportada: Confirme se o aviso aparece e a validação é concluída.
- Dispositivo Android atual: Confirme se os padrões de DNS Privado e MAC randomizado não deixam o usuário desamparado.
- Build de kiosk gerenciado: Confirme se a política permite o aplicativo do portal e se a WebView renderiza a página.
Em cada dispositivo, aguarde o status de validado e abra dois aplicativos, não apenas o navegador. Um único celular aprovado prova muito pouco, pois a detecção varia por versão do Android, suporte a DHCP e política do dispositivo. Faça a liberação para convidados somente após a aprovação de todos os três.
Se os visitantes da sua rede Android continuarem encontrando um portal que não exibe a solicitação, não valida ou não permanece conectado, o Purple Access pode ajudar você a executar um portal cativo personalizado para visitantes pontuais e Passpoint ou OpenRoaming para dispositivos recorrentes nos pontos de acesso que você já possui. Fale conosco para testar seu dispositivo Android mais antigo, seus telefones atuais e qualquer estrutura de quiosque gerenciado antes da sua próxima implantação, garantindo que o login funcione de primeira.
