Portal cativo para WiFi: Como funciona e quem precisa de um
Saiba o que é um portal cativo para WiFi, como os espaços o utilizam, que regras de consentimento se aplicam e que opções de integração se adequam à sua rede.
Se um convidado se pode ligar ao seu WiFi e navegar de imediato, com o que concordou exatamente e o que descobriu sobre ele? Essa é a lacuna que um portal cativo para WiFi preenche, mas apenas se separar três tarefas que são frequentemente agrupadas num único ecrã. Uma tarefa controla o acesso à rede. Uma segunda regista a aceitação dos seus termos de utilização. Uma terceira solicita o consentimento de marketing, e não é a mesma coisa que as outras duas.
Uma receção pode dar a entrada a alguém, explicar as regras da casa e convidar a pessoa a aderir a uma lista de correio. São ações relacionadas, mas não constituem uma única decisão. Quando os espaços as tratam numa única caixa de seleção, os convidados ficam confusos, o consentimento fica fragilizado e os dispositivos que nunca abrem um navegador podem passar despercebidos ou ficar bloqueados.
Índice
- Como funciona um portal cativo etapa por etapa
- Onde os locais utilizam um portal cativo
- Dados dos convidados, consentimento e o que solicitar
- Métodos de início de sessão comparados por esforço e dados
- Por que razão os portais cativos falham e como o prevenir
- Opções de integração com a sua rede existente
- Escolha a configuração de portal de que o seu local necessita
Como funciona um portal cativo passo a passo
Pense na receção de um hotel. Todos os hóspedes passam pelo balcão antes de recolherem a chave do quarto, e um portal funciona da mesma forma entre a ligação WiFi e o acesso à internet. O visitante liga-se primeiro à rede, mas essa ligação, por si só, não concede uma navegação sem restrições.
Imagine que um cliente num café toca no nome da sua rede. O telemóvel associa-se a um ponto de acesso e obtém as definições da rede local, mas o gateway mantém-no num estado restrito. Quando tenta navegar, esse pedido é intercetado e a pessoa é redirecionada para a página do seu portal em vez do site que solicitou.
Essa é a transação que a documentação do portal cativo da Advantech descreve, na qual um utilizador se junta a uma rede aberta ou semiaberta e é redirecionado para um portal que pode solicitar credenciais, pagamento, registo ou aceitação de termos antes de conceder o acesso. Em seguida, a pessoa autentica-se aceitando os termos, inserindo um e-mail ou pagando. Assim que conclui essa etapa, a rede autoriza o seu dispositivo e permite o tráfego normal.
| Etapa | O que acontece |
|---|---|
| 1. Associação | O dispositivo junta-se à rede de convidados |
| 2. Interceção | O pedido do navegador é redirecionado para a página do portal |
| 3. Autenticação | O convidado insere um e-mail, aceita os termos ou paga |
| 4. Autorização | A rede concede ao dispositivo acesso à internet |
| 5. Fim da sessão | O temporizador expira e o dispositivo regressa ao portal |
O mesmo fluxo aplica-se num aeroporto ou num pequeno café, porque o portal é onde a política de rede decide quem fica online. Quando o temporizador expira, a autorização termina e o dispositivo regressa ao portal.
Experimente este teste: Ligue um telemóvel à sua rede de convidados, abra uma página HTTP simples e confirme que a página de início de sessão aparece antes de qualquer navegação funcionar.
Onde os espaços utilizam um portal cativo
O tipo do seu espaço deve definir a função do portal antes de alguém conceber o ecrã. Um café, um hotel e um hospital não precisam do mesmo passo de início de sessão e forçar o mesmo modelo aos três cria atritos em locais diferentes.
| Tipo de espaço | Objetivo | Etapa de início de sessão | Duração típica da sessão |
|---|---|---|---|
| Café e restaurante | Início de sessão rápido e lista de convidados | Termos e e-mail opcional | 1 a 2 horas |
| Hotel e alojamento | Acesso associado a um quarto ou reserva | Verificação de reserva ou quarto, código de acesso ou voucher | Duração da estadia |
| Centro comercial | Medir visitas recorrentes | Início de sessão por e-mail ou conta que reconhece convidados recorrentes | 2 a 4 horas |
| Evento, espaço de coworking ou hospital | Acesso com limite de tempo | Código de acesso ou voucher | Dia do evento ou período reservado |
Cafés, hotéis e centros comerciais
Imagine que um cliente de um café se liga entre o momento em que faz o pedido e o momento em que se senta. Vê um ecrã com os termos e uma caixa de e-mail opcional, toca em ligar e fica online em segundos. Adicione mais cinco campos e ele mudará para os dados móveis.
Um hotel enfrenta o risco oposto. Se o portal não verificar um quarto ou reserva, qualquer pessoa no átrio ou na rua pode utilizar a largura de banda destinada aos hóspedes pagantes. Os centros comerciais enfrentam um problema de medição. Sem uma lógica que reconheça um dispositivo ou conta recorrente, cada visita parece uma primeira visita e as visitas repetidas não podem ser medidas.
Eventos, espaços de coworking e hospitais
Estes locais preocupam-se mais com o temporizador de sessão e com o código de acesso do que com o formulário. Um passe diário, uma marcação ou um bilhete para um evento definem quanto tempo deve durar o acesso. Quando esse período termina, o acesso deve ser encerrado de forma limpa, sem que a equipa tenha de remover manualmente os dispositivos.
Independentemente da sua configuração, vale a pena rever estes erros comuns em WiFi públicos explicados antes de assumir que uma página de início de sessão por si só torna os convidados seguros. Uma rede exclusiva para funcionários protegida com uma chave gerida não ganha nada com um portal. Apenas adiciona um passo de que a sua equipa não precisa.
Defina o resultado único que a sua rede de convidados deve proporcionar. Essa frase determinará o seu método de início de sessão muito melhor do que uma lista de campos que gostaria de recolher.
Dados dos convidados, consentimento e o que solicitar
Aceder à internet tem de significar obrigatoriamente ceder dados pessoais? Muitos espaços assumem que sim e criam o formulário mais longo que conseguem implementar. As evidências mostram que isso é uma escolha, não um requisito.
Num estudo académico de 2019 sobre 67 hotspots de WiFiWiFi públicos, 27 hotspots, ou seja, 40,3% da amostra, utilizaram início de sessão social ou uma página de registo para recolher dados pessoais e, em 19 casos, a conclusão desse processo era obrigatória para aceder à internet. O mesmo estudo revelou que 40 hotspots, ou seja, 59,7%, permitiam o acesso à internet sem solicitar dados pessoais explícitos. Assim, um portal não equivale automaticamente a um registo de marketing.
Três funções num único ecrã
Separe-os claramente no seu design e nos seus registos.
- Controlar o acesso à rede: O gateway decide se este dispositivo pode aceder à internet.
- Apresentar termos de utilização: O convidado aceita as condições de utilização aceitável para a própria ligação.
- Obter consentimento de marketing: O convidado aceita receber mensagens posteriormente, o que é uma decisão separada.
Eis o ponto que os leitores mais frequentemente ignoram. Apenas um consentimento explícito é tratado como autorização de marketing; aceitar os WiFi termos não concede autorização de marketing. Um convidado que marca uma caixa para aceder à Internet não concordou em receber a sua newsletter. Tratar essa marcação como permissão coloca a sua lista e a sua reputação em risco.
Um esquema compreensível para os convidados
Coloque uma caixa de seleção de termos obrigatórios junto do texto de utilização aceitável. Por baixo, coloque uma caixa de seleção de marketing separada e desmarcada com a sua própria frase clara, como um convite para receber ofertas por e-mail. Adicione uma hiperligação visível para a política de privacidade que abra antes de o convidado submeter qualquer informação, e não escondida após o início de sessão.
Esta separação alinha-se com as verificações práticas nesta GDPR lista de verificação de marketing por e-mail em conformidade para espaços. Também oferece aos convidados uma escolha real. Alguém pode recusar o marketing e, ainda assim, aceder à Internet, que é exatamente como deve funcionar.
Mais campos não significam mais valor. Cada pergunta adicional reduz as conclusões de formulário e acrescenta dados que fica responsável por proteger.
Quando um convidado aceita dar o seu consentimento, o portal pode armazenar o seu e-mail, data da visita e local de preferência num registo central. Quando um convidado se liga e inicia sessão utilizando o seu endereço de e-mail ou um perfil social, capturamos esses dados e armazenamo-los num CRM centralizado. É assim que um espaço constrói dados próprios dos quais é proprietário, em vez de depender do público de uma plataforma.
Responda a três perguntas antes do lançamento. Que dados são estritamente necessários para fornecer acesso? Durante quanto tempo manterá os registos de identidade e do dispositivo? Um convidado pode recusar o marketing e, ainda assim, aceder à Internet? Se alguma resposta for vaga, corrija o formulário antes de corrigir o design.
Comparação dos métodos de início de sessão por esforço e dados
Cada método de início de sessão pondera o esforço do convidado em relação aos dados recolhidos e à fiabilidade entre dispositivos. Leia a tabela de cima para baixo e verá essa compensação aumentar passo a passo.
| Método de início de sessão | Dados recolhidos | Esforço do convidado | Melhor adequação |
|---|---|---|---|
| Clique simples apenas com termos | Apenas registo do dispositivo | Muito baixo | Cafés que pretendem um acesso rápido |
| Voucher ou código de acesso | Apenas validação de código | Baixo | Hotéis e eventos com acesso impresso ou pago |
| Registo por e-mail | Endereço de e-mail e autorização de marketing | Médio | Locais que pretendem criar uma lista de convidados |
| Início de sessão por rede social | Dados de perfil permitidos pelo fornecedor | Baixo | Convidados que preferem início de sessão com um clique |
| Código único por SMS | Número de telemóvel | Médio | Locais que necessitam de identidade verificada |
| Passpoint ou autenticação baseada em certificados | Credenciais do dispositivo, sem página de portal | Muito baixo após a configuração | Grandes recintos com dispositivos geridos |
Do menor volume de dados para o maior
O clique direto com aceitação de termos apenas exige um único toque e cria somente um registo do dispositivo. É rápido, mas não permite criar uma lista de visitantes. Um voucher ou código de acesso adiciona controlo sem perguntar quem é o visitante, o que se adequa a cartões impressos de hotéis e passes de eventos.
O registo por e-mail exige mais esforço e devolve um contacto útil, desde que a autorização de marketing se mantenha separada. Se estiver a ponderar essa opção face a outras vias de recolha, esta comparação do início de sessão por código QR versus WiFi início de sessão por WiFi para captura de e-mail ajuda-o a avaliar o esforço em relação à qualidade dos dados.
O início de sessão com redes sociais parece exigir apenas um toque, mas adiciona um redirecionamento de terceiros. Alguns navegadores e as pequenas janelas de início de sessão que os telemóveis utilizam para WiFi gerem mal esses redirecionamentos, e os convidados podem não se lembrar de uma palavra-passe que já não introduzem há anos. Os códigos de utilização única por SMS verificam um número, mas dependem de o convidado ter sinal de rede móvel e um número que aceite a mensagem.
A autenticação por Passpoint ou baseada em certificados remove a página do portal após a configuração. Requer um perfil gerido no dispositivo, pelo que se adequa mais a funcionários e a visitantes habituais do que a visitantes ocasionais que acedem à sua rede pela primeira vez.
Regra de decisão: Corresponda a etapa de início de sessão ao único resultado de que necessita, e não ao maior conjunto de campos que consegue recolher.
Selecione dois métodos agora. Irá testar ambos no seu hardware e com verificações de falha antes de escolher um.
Por que razão os portais cativos falham e como o evitar
Um portal não é apenas uma página personalizada. Antes do início de sessão, o gateway mantém cada dispositivo num estado restrito e permite apenas tráfego de deteção, de início de sessão e do portal. A maioria das falhas ocorre porque essa área de retenção foi mal construída ou testada de forma inadequada.
Quatro sintomas que os convidados notam
O portal nunca aparece. A maioria dos sites utiliza agora HTTPS e os navegadores rejeitam certificados substituídos, pelo que a antiga interceção HTTP não consegue apresentar a sua página de forma fiável. Em vez disso, os sistemas operativos executam verificações de conetividade, tais como os pedidos descritos na orientação do suporte de rede cativa da Apple para captive.apple.com através das portas TCP 80 e 443, para detetar se o acesso à internet está a ser intercetado.
A página é carregada com erros. O HTML chega, mas as folhas de estilo, scripts, fontes ou redirecionamentos do fornecedor de identidade são bloqueados dentro do estado restrito. Aloje os recursos do portal localmente ou adicione à lista de permissões todos os pontos de extremidade de que a página necessita.
Alguns convidados ignoram o portal. Se filtrar IPv4 mas deixar o IPv6 aberto, o tráfego pode contornar a sua regra. Dê o mesmo tratamento a ambos os caminhos.
Os convidados entram num ciclo de regresso ao início de sessão. O temporizador de autorização expira, ou a itinerância entre pontos de acesso interrompe a sessão, e o convidado é redirecionado repetidamente. Isto é percetível como um falha no WiFi, mesmo quando o sinal é forte.
Testes a realizar antes do lançamento
- Testar dispositivos reais: Realize testes em iOS, Android, Windows, macOS e em pelo menos um dispositivo IoT, como uma impressora ou TV.
- Medir dois tempos: Registe o tempo até ao portal e o tempo até à autorização em cada dispositivo.
- Forçar a expiração da sessão: Confirme que o convidado regressa ao portal de forma limpa e consegue iniciar sessão novamente.
- Fazer roaming durante a ligação: Desloque-se entre pontos de acesso com um endereço MAC privado ativo e verifique se o acesso se mantém.
Mantenha uma alternativa documentada para quando a deteção do portal falhar, como um endereço curto que a equipa possa fornecer aos convidados para abrirem manualmente. Não enfraqueça a segurança mudando a rede para totalmente aberta.
Por fim, ajude os convidados a identificar tentativas de phishing. O nome da rede deve corresponder ao espaço, o endereço do portal deve estar no próprio domínio do espaço e o navegador deve apresentar um certificado TLS válido para esse domínio. Um portal legítimo nunca solicita dados bancários ou palavras-passe de redes sociais.
Opções de integração com a sua rede existente
Não precisa de substituir toda a sua rede para adicionar um portal. Comece por compreender como os dispositivos detetam a existência do portal, pois isso determina a fiabilidade nos telemóveis que nunca abrem primeiro um navegador.
A imagem abaixo mostra como o portal se situa entre os seus pontos de acesso e os sistemas que recebem os registos dos convidados.
O caminho das normas
Sob a abordagem descrita no guia de administração do portal cativo da Fortinet, a RFC 8910 define como uma rede anuncia o endpoint do seu portal API através da opção 114 do DHCPv4, DHCPv6 ou Anúncios de Router IPv6. A RFC 8908 especifica depois um JSON HTTPS API utilizando o tipo de media application/captive+json, expondo se o cliente ainda está cativo, o URI de início de sessão visível para o utilizador e informações de sessão, tais como o tempo de acesso restante.
Em termos simples, a rede indica diretamente ao sistema operativo onde iniciar sessão e quanto tempo dura o acesso. Isso reduz a dependência de redirecionamentos com falha, especialmente quando as aplicações utilizam HTTPS ou certificate pinning. Tanto o ponto de extremidade de API como o portal têm de utilizar TLS com validação de certificado; caso contrário, um atacante poderia forjar um estado autorizado ou alterar o destino do início de sessão.
Este vídeo curto explica como esses pontos de integração se articulam na prática.
Mapear cada ponto de ligação
Uma camada de portal pode ser integrada sobre o seu hardware existente, incluindo Cisco Meraki, HPE Aruba e Ubiquiti UniFi, e pode funcionar com ou sem uma plataforma dedicada de WiFi nos seus Inícios de Sessão. O seu responsável de TI deve mapear quatro pontos antes de escolher as definições.
- Controlador do ponto de acesso: É responsável pelo nome da rede, estado restrito e reencaminhamento ou anúncio API.
- Fonte de identidade: Verifica números de quarto, vouchers, contas de funcionários ou início de sessão social.
- Sistema de registo de convidados: Recebe os dados de contacto consentidos, conforme apresentado nas integrações Purple WiFi disponíveis.
- Certificado TLS: Deve corresponder ao domínio do portal que os convidados veem, estando a renovação sob a responsabilidade de uma pessoa designada.
Execute um teste de decisão. Se a sua rede suportar o anúncio RFC 8910 em IPv4 e IPv6, mantenha-o e teste as respostas JSON. Se não suportar, planeie um redirecionamento baseado no navegador com uma alternativa documentada.
Escolha a configuração de portal de que o seu espaço necessita
Três decisões distintas escondem-se num único ecrã de início de sessão: acesso à rede, aceitação dos termos e consentimento de marketing. O acesso coloca o dispositivo na rede. A aceitação dos termos regista que o convidado concordou com as suas regras. O consentimento de marketing é uma autorização deliberada e a aceitação dos termos da WiFi não o concede. Uma configuração que una essas opções numa única caixa de seleção recolhe consentimento que não pode utilizar ou bloqueia convidados que teriam iniciado sessão de bom grado.
Três pontos de partida
Um café que necessite de acesso rápido e de uma lista de subscrições (opt-in) deve utilizar termos acrescidos de e-mail opcional. O campo do e-mail e a opção de subscrição de marketing aparecem apenas quando o visitante os escolhe ativamente. Verifique primeiro o sistema de registo de visitantes, para que os novos contactos vão para um local útil.
Um hotel que associe o acesso a reservas deve utilizar a verificação do quarto ou da reserva, ou vouchers emitidos no check-in. Recolha a referência da estadia necessária para autorizar o acesso e não campos de perfil adicionais. Verifique primeiro a fonte de identidade, pois a equipa da receção terá de resolver eventuais divergências.
Um grupo com múltiplos locais que necessite de consistência deve padronizar um registo de consentimento e relatórios em todos os locais. O registo por e-mail com a mesma opção de subscrição (opt-in) em separado em todo o lado significa que cada local trata as recusas da mesma forma. Verifique primeiro os relatórios e a retenção de dados.
Dispositivos que o portal nunca verá
Um portal cativo apenas funciona em hardware capaz de abrir um navegador. Smart TVs, impressoras, terminais de pagamento e gadgets de quarto não têm onde renderizar a página, pelo que permanecem no estado restrito indefinidamente. Forneça a esses dispositivos um caminho separado, como chaves por dispositivo numa rede de funcionários ou de dispositivos, e reserve o portal para telemóveis e portáteis que possam apresentar um início de sessão.
Antes do lançamento, confirme se o seu hardware suporta o caminho de normas ou se a sua alternativa está documentada. Execute as verificações de dispositivo, expiração, itinerância e IPv6 com dispositivos reais de convidados, e não apenas com um portátil no escritório.
Purple Engage adapta-se a espaços que pretendem que o início de sessão alimente ações de marketing futuras. É um sistema de marketing tudo-em-um para espaços físicos que transforma cada início de sessão WiFi numa visita de regresso, com ou sem Purple WiFi, e comprova quais as campanhas que o conseguiram. Combina inícios de sessão WiFi, vendas de caixa, reservas, formulários, ficheiros, mensagens e respostas a inquéritos num único registo de convidado associado por e-mail. Como funciona com ou sem Purple WiFi e lê os seus sistemas existentes, pode ligá-lo ao hardware e às caixas que já utiliza.
Faça uma coisa esta semana. Anote o resultado único que o seu portal tem de proporcionar e, em seguida, mapeie o seu método de início de sessão, campos de dados e primeira verificação de integração com base nesse resultado.
Se está a configurar um portal cativo para WiFi e pretende que cada início de sessão com consentimento se torne num registo de convidado útil, o Purple Engage reúne os inícios de sessão via WiFi com vendas de caixa, reservas, formulários e respostas a inquéritos num único local. Visite o site para ver como funciona no hardware que já utiliza e como ajuda a transformar uma primeira ligação numa visita de regresso.