Como Criar uma Página de Login WiFi Personalizada para a Sua Marca
Este guia fornece uma referência abrangente e pronta para implementação para gestores de TI, arquitetos de rede e diretores de operações de espaços sobre como criar uma página de login WiFi de convidado totalmente personalizada — cobrindo a arquitetura do captive portal, personalização HTML/CSS, conformidade com o GDPR e estratégia de recolha de dados. Abrange desde os fundamentos técnicos até cenários de implementação no mundo real em hotelaria e retalho, com resultados de negócio mensuráveis em cada etapa. Para organizações que utilizam a plataforma de WiFi de convidado da Purple, o guia corresponde diretamente às capacidades de criação de portais, análise e gestão de consentimento da plataforma.
🎧 Ouça este Guia
Ver Transcrição
Executive Summary
A página de login WiFi de convidado — comummente referida como captive portal ou splash page — é frequentemente a primeira interação digital de marca que um visitante tem com a sua organização. Apesar disso, a maioria das implementações empresariais depende de ecrãs de apresentação genéricos, fornecidos pelo fornecedor, que não possuem identidade de marca e não capturam dados úteis. Este guia aborda diretamente essa lacuna.
Uma experiência de login Guest WiFi totalmente personalizada não é uma atualização cosmética. É um ativo de aquisição de dados, um sinal de confiança e um instrumento de conformidade simultaneamente. Quando implementado corretamente, pode aumentar as taxas de captura de e-mail de um dígito para 30–40 por cento dos convidados que se conectam, alimentar dados primários diretamente no seu CRM e fornecer um registo de consentimento GDPR auditável para cada sessão de utilizador. Para organizações que operam em ambientes de hospitality , retail , healthcare ou transport , o caso comercial é direto.
Este guia abrange a arquitetura técnica subjacente aos captive portals, a camada de personalização HTML/CSS, o processo de implementação em cinco etapas, os requisitos de conformidade sob o GDPR e dois estudos de caso detalhados com resultados mensuráveis. A plataforma WiFi Analytics da Purple é referenciada ao longo do guia como um exemplo de implementação concreta.
Technical Deep-Dive
How a Captive Portal Works
Um captive portal opera na camada de rede, intercetando o pedido HTTP inicial de um dispositivo de convidado e redirecionando-o para uma página de login antes de conceder acesso total à internet. O mecanismo é padronizado em todos os principais fornecedores de LAN sem fios e opera independentemente do padrão de encriptação em uso — o que significa que é totalmente compatível com implementações WPA3 que utilizam Simultaneous Authentication of Equals (SAE).
Os componentes centrais de uma arquitetura de captive portal moderna são ilustrados abaixo.
O fluxo é o seguinte. Quando um dispositivo de convidado se associa ao ponto de acesso e tenta carregar qualquer URL HTTP, o controlador da LAN sem fios ou o dispositivo de gateway interceta o pedido e emite um redirecionamento 302 para o controlador do captive portal. O controlador serve a página de login HTML/CSS personalizada. Assim que o utilizador completa o fluxo de autenticação — seja através de um formulário de e-mail, login social (OAuth 2.0 via Facebook, Google ou Apple), ou um método contínuo como OpenRoaming — o controlador comunica com um servidor RADIUS utilizando IEEE 802.1X ou MAC Authentication Bypass (MAB) para conceder ao dispositivo acesso à VLAN da internet. Os dados capturados durante a autenticação são simultaneamente encaminhados para a plataforma de dados de convidados ou CRM através de uma chamada de API segura, com o registo de consentimento GDPR gravado num armazenamento de dados compatível.
É importante notar que a própria página do captive portal carrega num ambiente de navegador restrito — o Captive Network Assistant (CNA) em iOS e Android — antes que o dispositivo tenha acesso total à internet. Isto tem uma implicação crítica para o desenvolvimento front-end: todos os ativos devem ser auto-hospedados no controlador do portal. Recursos CDN externos, Google Fonts e bibliotecas JavaScript de terceiros não serão carregados neste ambiente. Cada folha de estilo, ficheiro de fonte e imagem deve ser agrupado com a página do portal e servido a partir do próprio servidor web do controlador.
The HTML/CSS Customisation Layer
A própria página de login é um documento HTML5 padrão com uma folha de estilo CSS associada. As plataformas modernas de captive portal — incluindo a Purple — expõem um editor visual que gera este código, mas compreender a estrutura subjacente é essencial para as equipas de TI que precisam de aplicar padrões de marca ou resolver problemas de renderização.
As principais variáveis CSS a controlar são:
| CSS Property | Brand Element | Recommended Approach |
|---|---|---|
background-color |
Fundo da página | Usar um valor hexadecimal plano ou gradiente CSS; evitar imagens rasterizadas |
font-family |
Tipografia | Incorporar ficheiros de fonte WOFF2 localmente; não referenciar Google Fonts |
color (headings) |
Cor secundária da marca | Corresponder exatamente às diretrizes da marca |
background-color (CTA button) |
Cor primária da marca | Usar o valor hexadecimal exato das diretrizes da marca |
border-radius |
Forma do botão e do contentor | 12px para contentores, 6px para elementos pequenos |
max-width (form container) |
Layout mobile-first | 480px máximo para renderização móvel ideal |
A restrição de peso da página é o requisito técnico mais comummente violado em implementações de captive portal. O limite prático é de 500 kilobytes no total para toda a página, incluindo todos os ativos. Isto garante uma renderização fiável em ligações lentas ou congestionadas antes da autenticação. Use o formato SVG para logótipos (tipicamente 5–20 KB), WOFF2 incorporado localmente para fontes (tipicamente 30–80 KB por peso) e gradientes CSS ou cores planas em vez de fundos fotográficos.
Authentication Methods
A escolha do método de autenticação tem um impacto direto nas taxas de captura de dados e na postura de conformidade.
| Method | Data Captured | Conversion Rate | Compliance Notes |
|---|---|---|---|
| Formulário de e-mail | E-mail, nome, campos personalizados | Médio (25–40%) | Controlo total do GDPR; recomendado |
| Login social (OAuth) | E-mail, nome, dados de perfil | Alto (35–55%) | Requer DPA com fornecedor social |
| SMS / OTP | Número de telemóvel | Médio (20–35%) | Requer gateway SMS; aplica-se PECR |
| Click-through (sem dados) | Nenhum | Muito alto (70–90%) | Sem dadosum valor; usar apenas onde necessário |
| OpenRoaming / Passpoint | Identidade verificada pela operadora | Sem interrupções | Ecossistema Eduroam/WBA; uso empresarial |
Para a maioria das implementações comerciais, uma combinação de formulário de e-mail e login social — com uma caixa de seleção de consentimento GDPR claramente apresentada — oferece o equilíbrio ideal entre taxa de conversão e qualidade dos dados.
Guia de Implementação
Uma implementação bem-sucedida de captive portal segue cinco fases distintas. Saltar ou comprimir qualquer fase é a principal causa de problemas pós-implementação.
Fase 1 — Recolha de Requisitos. Convocar um grupo de trabalho multifuncional incluindo marketing (ativos de marca, texto, linguagem de consentimento), jurídico (revisão GDPR, política de privacidade) e engenharia de rede (arquitetura VLAN, configuração RADIUS, lista de permissões DNS). Definir os campos de dados exatos a capturar, o URL de redirecionamento pós-autenticação e a linguagem de opt-in para consentimento de marketing. Obter aprovação por escrito do departamento jurídico sobre o mecanismo de consentimento antes do início do desenvolvimento.
Fase 2 — Design e Desenvolvimento. Construir a página do portal como um documento HTML/CSS autónomo. Impor o limite de peso da página de 500 KB. Testar a renderização no iOS Safari (CNA), Android Chrome (CNA) e navegadores de desktop. Validar a cadeia de certificados SSL — o domínio do portal deve ter um certificado fidedigno, pois um aviso de certificado não fidedigno fará com que a maioria dos utilizadores abandone o login. Garantir que o formulário é totalmente acessível (WCAG 2.1 AA mínimo).
Fase 3 — Integração. Ligar o portal à sua plataforma de dados de convidados ou CRM através da API da plataforma. Configurar o servidor RADIUS (ou usar o serviço RADIUS alojado da plataforma). Configurar o redirecionamento pós-autenticação. Configurar a segmentação VLAN para isolar o segmento de rede de pré-autenticação dos recursos internos. Testar o fluxo completo de ponta a ponta — associação de dispositivo, redirecionamento do portal, autenticação, autorização RADIUS, escrita de dados no CRM e redirecionamento pós-autenticação — numa rede de teste antes de passar para a produção.
Fase 4 — Implementação Piloto. Lançar num único local ou num grupo piloto definido. Monitorizar quatro métricas chave durante os primeiros 30 dias: taxa de sucesso de autenticação (meta >95%), tempo médio de carregamento da página (meta <3 segundos), taxa de captura de dados (medição de referência) e falhas de autorização RADIUS (meta <1%). Resolver quaisquer problemas antes de prosseguir para o lançamento completo.
Fase 5 — Otimização e Governança. Rever as taxas de captura de dados mensalmente. Testar variantes de texto de título e de botão CTA. Atualizar o design do portal quando as diretrizes de marca mudarem. Rever a linguagem de consentimento GDPR sempre que as atividades de processamento de dados mudarem. Realizar uma revisão de segurança anual da infraestrutura do portal, incluindo a renovação do certificado SSL, a aplicação de patches no servidor RADIUS e a revisão da lista de permissões DNS.
Melhores Práticas
Fidelidade à Marca
O portal deve passar por uma Verificação de Fidelidade à Marca de cinco pontos antes da implementação: variante de logótipo correta no tamanho mínimo (30px digital); cor do botão principal correspondente ao valor hexadecimal exato da marca; família de fontes consistente com as diretrizes de marca digital; tom do título consistente com a voz da marca; e consistência visual com o website e a aplicação da marca. Qualquer portal que falhe esta verificação deve ser devolvido à fase de design.
Arquitetura de Conformidade GDPR
Ao abrigo do UK GDPR e do EU GDPR, o mecanismo de consentimento deve ser explícito, desagregado e granular. A aceitação dos termos de serviço e o opt-in para comunicações de marketing devem ser apresentados como caixas de seleção separadas e desmarcadas. Agrupá-los numa única caixa de seleção não está em conformidade. Cada evento de consentimento deve ser registado com um carimbo de data/hora, o texto exato de consentimento apresentado e o identificador do utilizador. A plataforma da Purple armazena estes registos num arquivo de consentimento auditável que pode ser exportado para revisão regulamentar.
Postura de Segurança
O segmento de rede de pré-autenticação deve ser isolado de todos os recursos internos através de segmentação VLAN. Apenas as entradas da lista de permissões DNS necessárias para o funcionamento do portal — o domínio do controlador do portal, os endpoints OAuth de login social e quaisquer domínios CDN usados para ativos auto-hospedados — devem ser acessíveis antes da autenticação. Pós-autenticação, os convidados devem ser colocados numa VLAN de convidado dedicada com acesso apenas à internet, sem rota para sub-redes internas. Esta arquitetura alinha-se com o Requisito 1.3 do PCI DSS para segmentação de rede.
Para uma comparação detalhada dos tipos de página do portal, consulte Página de Destino WiFi vs. Página Splash: Qual a Diferença? .
Estudos de Caso Reais
Estudo de Caso 1: Cadeia Hoteleira do Reino Unido — Hotelaria
Um grupo hoteleiro de média dimensão, com 45 propriedades em todo o Reino Unido, utilizava a página splash predefinida fornecida pelo seu fornecedor de LAN sem fios. A página não tinha marca, carregava lentamente em dispositivos móveis e não apresentava formulário de captura de dados. Taxa de captura de e-mail: aproximadamente 8% dos hóspedes que se ligavam.
A equipa de TI implementou a plataforma Guest WiFi da Purple em todas as 45 propriedades, substituindo a página splash do fornecedor por um captive portal totalmente personalizado com a marca. O novo portal utilizava as cores exatas da marca do grupo hoteleiro, tipografia Poppins e um layout de ecrã único com um campo de e-mail, um campo de primeiro nome e uma caixa de seleção de consentimento de marketing em conformidade com o GDPR. O peso total da página foi otimizado para 380 KB. O redirecionamento pós-autenticação foi definido para a página de destino do programa de fidelidade do hotel.
Resultados aos 90 dias: a taxa de captura de e-mail aumentou de 8% para 38% dos hóspedes que se ligavam. Os dados capturados foram integrados no CRM do grupo hoteleiro, permitindo uma campanha de e-mail de re-engajamento direcionada a hóspedes anteriores. As receitas de reservas diretas atribuíveis à campanha de e-mail aumentaram 14% ano a ano nas propriedades piloto. O arquivo de consentimento GDPR forneceu um registo de auditoria completo para todos os 45 locais.
Estudo de Caso 2: Retalhista de Moda Europeu — Retalho
Um retalhista de moda com 120 lojas em cinco mercados europeus estava a implementar WiFi para convidados como parte de um programa de transformação digital. O requisito era um portal único, gerido centralmente e com a marca, com um idioma por mercadolocalização de idiomas (inglês, francês, alemão, espanhol, italiano) e uma única integração de CRM no Salesforce.
O retalhista implementou uma plataforma WiFi de convidado gerida na cloud com uma configuração de portal centralizada. Os ativos da marca e o CSS foram geridos a partir de uma única consola de administração, com substituições por local e por região aplicadas para o idioma e para a linguagem de consentimento localizada. A integração com o Salesforce utilizou o conector de CRM nativo da plataforma.
Resultados aos seis meses: foi construído um ativo de dados primários de mais de 400.000 perfis de convidados com consentimento em todas as 120 lojas. As campanhas de email para este público alcançaram uma taxa de abertura média de 28%, em comparação com uma referência da indústria de 12% para o retalho. O retalhista atribuiu um aumento de 9% nas visitas repetidas à loja nos seis meses seguintes à implementação, com base na modelagem de atribuição de CRM. Consulte a plataforma WiFi Analytics da Purple para as capacidades de análise e atribuição utilizadas nesta implementação.
Resolução de Problemas e Mitigação de Riscos
Portal não é exibido no iOS. O iOS utiliza um Captive Network Assistant (CNA) que renderiza o portal numa visualização WebKit restrita. Certifique-se de que o domínio do portal não está na lista de redes conhecidas da Apple, que o portal responde corretamente à sonda de deteção de Captive Portal da Apple (/hotspot-detect.html) e que todos os ativos são servidos via HTTP (não HTTPS) no redirecionamento inicial — o CNA não segue redirecionamentos HTTPS na primeira solicitação.
Alta taxa de falha de autenticação. Verifique os registos do servidor RADIUS para códigos de erro específicos. As causas comuns incluem desvio de relógio entre o servidor RADIUS e o ponto de acesso (sincronização NTP necessária), certificados expirados no servidor RADIUS e incompatibilidades de formato de endereço MAC entre o ponto de acesso e o servidor RADIUS.
Baixa taxa de captura de dados apesar do alto volume de conexões. Reveja a contagem de campos do formulário — cada campo adicional reduz a conversão em aproximadamente 5–10%. Reveja o tempo de carregamento da página — se o portal demorar mais de 3 segundos a carregar, o abandono aumenta drasticamente. Reveja a linguagem de consentimento — texto de consentimento excessivamente legalista reduz as taxas de adesão.
Pedido de auditoria GDPR. A plataforma da Purple exporta um registo de consentimento completo para qualquer endereço de email ou intervalo de datas, sob demanda. Certifique-se de que a sua política de retenção de dados está configurada corretamente — sob o GDPR do Reino Unido, os dados pessoais não devem ser retidos além do período necessário para o fim declarado.
Inconsistência da marca em vários locais. Centralize a gestão da configuração do portal. Qualquer personalização ao nível do local deve ser limitada a texto e idioma localizados; as cores da marca, tipografia e logótipo devem ser bloqueados ao nível da configuração global.
ROI e Impacto no Negócio
O ROI de um Captive Portal personalizado é medido em três dimensões: valor do ativo de dados, atribuição direta de receita e eficiência operacional.
Valor do Ativo de Dados. O principal resultado de uma implementação de Captive Portal é um ativo de dados primários — uma base de dados de perfis de convidados com consentimento e endereços de email verificados. O valor deste ativo é determinado pela taxa de captura, pela taxa de adesão e pela qualidade dos dados. Um local com 500 conexões diárias, uma taxa de captura de 35% e uma taxa de adesão de 70% construirá uma base de dados de aproximadamente 44.000 perfis com consentimento por ano. Com um ROI de marketing por email padrão da indústria de £42 por cada £1 gasto, o valor comercial deste ativo é substancial.
Atribuição Direta de Receita. A plataforma WiFi Analytics da Purple fornece relatórios de atribuição ao nível do CRM, ligando campanhas de email específicas a visitas e transações no local. Isto permite um cálculo direto da receita atribuível ao programa de captura de dados do Captive Portal.
Eficiência Operacional. Uma plataforma de portal gerida centralmente elimina a necessidade de trabalho de configuração de TI por local quando as diretrizes da marca mudam. Uma única atualização de CSS propaga-se em todos os locais simultaneamente, reduzindo a sobrecarga operacional de manter a consistência da marca em escala.
| Métrica | Portal Típico Sem Marca | Portal de Marca (Purple) | Aumento |
|---|---|---|---|
| Taxa de captura de email | 5–10% | 30–40% | 3–4x |
| Taxa de adesão de marketing | N/A | 60–75% das capturas | — |
| Engajamento pós-autenticação | Nenhum | Página de fidelidade / oferta | Direto |
| Prontidão para auditoria GDPR | Manual | Exportação automatizada | Significativo |
| Consistência da marca | Nenhuma | Imposto centralmente | Total |
Para contexto de arquitetura de rede relevante para implementações multi-site, consulte Os Principais Benefícios do SD-WAN para Empresas Modernas , que aborda como o SD-WAN simplifica a infraestrutura de rede para implementações distribuídas de Captive Portal.
Termos-Chave e Definições
Captive Portal
A network mechanism that intercepts a guest device's HTTP requests and redirects them to a login or authentication page before granting full internet access. Operates at the network layer, independent of the wireless encryption standard in use.
IT teams encounter this term when configuring wireless LAN controllers, cloud WiFi management platforms, or gateway appliances. It is the technical name for what end users experience as a 'WiFi login page'.
Captive Network Assistant (CNA)
A restricted browser environment built into iOS and Android that automatically opens when the operating system detects a captive portal. It renders the portal page in a sandboxed WebKit view with no access to cookies, local storage, or external CDN resources.
Critical for front-end developers building portal pages. Any asset that cannot be loaded from the portal controller itself will fail to render in the CNA, causing visual breakage or page load failures.
RADIUS (Remote Authentication Dial-In User Service)
A networking protocol that provides centralised authentication, authorisation, and accounting (AAA) for network access. In a captive portal deployment, the portal controller communicates with the RADIUS server to grant or deny network access after the user completes the authentication flow.
Network engineers configure RADIUS servers (or use a hosted RADIUS service provided by the portal platform) as part of the captive portal backend. IEEE 802.1X uses RADIUS as its authentication protocol.
IEEE 802.1X
An IEEE standard for port-based network access control that provides an authentication mechanism for devices connecting to a LAN or WLAN. In enterprise guest WiFi deployments, it is used in conjunction with a RADIUS server to authenticate users before granting network access.
Relevant when configuring enterprise-grade captive portals, particularly in environments where MAC Authentication Bypass (MAB) is insufficient and stronger identity verification is required.
MAC Authentication Bypass (MAB)
An authentication method in which a device's MAC address is used as its credential for network access. The access point sends the MAC address to the RADIUS server, which either approves or denies access based on a pre-configured allowlist.
Used in captive portal deployments to enable automatic re-authentication for returning devices without requiring the user to re-enter credentials. Commonly used for known corporate devices or returning guests.
GDPR Consent Record
A timestamped record of a user's explicit consent to data processing, including the exact consent text presented, the date and time of consent, and the user's identifier (typically email address). Required under UK GDPR and EU GDPR Article 7(1) as evidence that consent was obtained.
Captive portal platforms must generate and store a consent record for every user who opts in to marketing communications. This record must be exportable for regulatory audit purposes.
DNS Whitelist
A list of domain names that are accessible to a guest device before it has completed captive portal authentication. The whitelist must include the portal controller domain, any social login OAuth endpoints, and any CDN domains used for self-hosted portal assets.
Network engineers configure the DNS whitelist on the wireless LAN controller or gateway appliance. An incorrectly configured whitelist is a common cause of portal rendering failures, particularly for social login flows.
Post-Authentication Redirect
The URL to which a guest device's browser is redirected immediately after the user successfully completes the captive portal authentication flow. This is the first page the user sees with full internet access.
The post-authentication redirect is a high-value commercial touchpoint. It should be set to a landing page that drives a specific action — loyalty programme sign-up, app download, current promotion — rather than defaulting to the user's originally requested URL.
WPA3-SAE (Simultaneous Authentication of Equals)
The authentication protocol used in WPA3 Personal mode, replacing the Pre-Shared Key (PSK) handshake used in WPA2. SAE provides stronger resistance to offline dictionary attacks and forward secrecy. It is fully compatible with captive portal deployments.
IT teams evaluating network security upgrades should be aware that migrating from WPA2 to WPA3 does not require changes to the captive portal architecture. The portal mechanism operates at the network layer, above the encryption layer.
OpenRoaming
A WiFi roaming standard developed by the Wireless Broadband Alliance (WBA) that allows users to automatically connect to participating networks using their existing credentials (carrier, enterprise, or identity provider). Eliminates the need for manual captive portal authentication for enrolled users.
Relevant for enterprise and transport deployments where seamless connectivity is a priority. Purple operates as an identity provider within the OpenRoaming ecosystem under its Connect licence, enabling venues to offer automatic connection to enrolled users.
Estudos de Caso
A 200-room hotel in central London wants to replace its vendor-supplied splash page with a fully branded captive portal. The hotel's brand guidelines specify a dark navy primary colour (#011638), a gold accent (#C9A84C), and the Playfair Display serif font. The IT manager is concerned about iOS compatibility and GDPR compliance. How should this be approached?
Begin with a requirements workshop involving IT, marketing, and legal. Confirm the exact brand assets: SVG logo file, hex colour values, and font files (WOFF2 format for Playfair Display). For iOS compatibility, configure the wireless LAN controller to respond correctly to Apple's captive portal detection probe at /hotspot-detect.html, and ensure the initial redirect is HTTP (not HTTPS) — the CNA on iOS does not follow HTTPS redirects on the first request. The portal page itself should be served over HTTPS once the CNA has loaded it. For GDPR, present two separate, unticked checkboxes: one for terms of service acceptance (required to connect) and one for marketing communications (optional). Record each consent event with a timestamp and the exact consent text version. Optimise the page to under 500 KB by embedding the Playfair Display WOFF2 file locally (do not reference Google Fonts), using the SVG logo, and using a CSS gradient for the background rather than a photographic image. Set the post-authentication redirect to the hotel's loyalty programme or a current promotions page. Deploy to a single floor as a pilot, monitor authentication success rate and page load time for 14 days, then roll out to the full property.
A national retail chain with 85 stores wants to deploy a consistent branded captive portal across all locations. Each store has a different wireless LAN vendor (a mix of Cisco, Aruba, and Ruckus hardware from historical acquisitions). The marketing team wants to be able to update the portal design centrally without involving IT at each site. How should the architecture be designed?
Deploy a cloud-hosted captive portal platform — such as Purple — that operates as a vendor-neutral overlay, independent of the underlying wireless hardware. The platform communicates with each access point via a RADIUS proxy or a cloud RADIUS service, meaning the portal controller is entirely decoupled from the hardware vendor. The portal page is hosted on the platform's CDN (with all assets self-hosted on the platform, not on external CDNs), and the platform's admin console allows centralised management of brand assets, CSS, and copy. Per-store customisations (store name in the headline, localised promotions) are managed via venue-level variables in the platform's template engine. When the marketing team updates the brand CSS, the change propagates to all 85 stores within minutes, with no per-site IT intervention required. The CRM integration is configured once at the platform level and applies to all venues. VLAN configuration at each site is a one-time setup task handled by the local IT team or the platform's onboarding service.
A conference centre hosting 50 events per year wants to offer event sponsors a co-branded WiFi login experience — showing the sponsor's logo alongside the venue's own branding — for the duration of each event. The IT team needs to be able to switch portal configurations between events with minimal manual effort. How should this be implemented?
Configure the captive portal platform with a library of portal templates — one master template per event type (conference, exhibition, gala dinner) — with sponsor logo and colour variables that can be updated via the admin console or API. For each event, the event operations team updates the sponsor logo URL and primary accent colour in the admin console, and the portal updates in real time. If the platform supports it, configure SSID-to-portal mapping so that a sponsor-specific SSID (e.g., 'EventName-WiFi') serves the co-branded portal, while the venue's permanent SSID serves the standard venue portal. Set the portal to revert to the standard venue template at a scheduled time after the event ends. Ensure the sponsor's logo is provided in SVG format and is pre-approved by the venue's brand team to ensure it meets the page weight and quality standards. The post-authentication redirect for event portals should point to the event's own landing page or the sponsor's campaign URL, with UTM parameters for attribution tracking.
Análise de Cenários
Q1. Your marketing director has sent you a Figma mockup of the new branded captive portal. It includes a full-screen photographic background image (exported as a 4.2 MB JPEG), the brand's custom serif font loaded from Google Fonts, and a Facebook Login button. You need to implement this design. What changes must you make before development begins, and why?
💡 Dica:Consider the technical constraints of the Captive Network Assistant environment and the page weight limit.
Mostrar Abordagem Recomendada
Three changes are required. First, the background image must be replaced with a CSS gradient or a heavily compressed WebP/SVG alternative under 100 KB — a 4.2 MB JPEG will cause the portal to time out on slow connections before it renders. Second, the Google Fonts reference must be replaced with a locally embedded WOFF2 font file served from the portal controller — the CNA environment has no internet access before authentication, so external font CDNs will fail to load. Third, the Facebook Login OAuth flow requires the Facebook OAuth endpoint domains to be added to the DNS whitelist on the wireless LAN controller, so the OAuth redirect can complete before full internet access is granted. Additionally, ensure the Facebook Login is accompanied by an email-based fallback option for users without Facebook accounts, and that the Facebook data processing agreement is in place with your legal team.
Q2. You are the IT manager for a hospital trust deploying guest WiFi across three sites. Your legal team has told you that the consent mechanism on the current portal is non-compliant with UK GDPR. You review the portal and find a single checkbox that reads: 'I agree to the Terms of Service and consent to receive marketing communications.' What is wrong with this, and how do you fix it?
💡 Dica:Consider the GDPR requirements for consent to be freely given, specific, and granular.
Mostrar Abordagem Recomendada
The consent mechanism is non-compliant on two counts. First, it bundles terms of service acceptance (a contractual requirement for network access) with marketing communications consent (an optional data processing activity) into a single checkbox. Under UK GDPR Article 7 and Recital 43, consent is not freely given if it is bundled with a service that the user cannot access without consenting. Second, the checkbox appears to be pre-ticked or required — marketing consent must be presented as an unticked, optional checkbox. The fix is to separate the two into distinct checkboxes: one required checkbox for terms of service acceptance (worded as 'I agree to the Terms of Service and Privacy Policy'), and one separate, unticked, optional checkbox for marketing communications (worded as 'I would like to receive news and offers from [Organisation Name] by email'). The consent record stored for each user must capture which checkboxes were ticked, the exact text of each consent statement, and the timestamp of the consent event. In a healthcare environment, additional care must be taken to ensure the privacy policy accurately describes all data processing activities, including any sharing with third-party analytics platforms.
Q3. A stadium operator wants to deploy a branded captive portal for 40,000 concurrent users during match days. Their current wireless infrastructure supports a maximum of 500 concurrent RADIUS authentication requests per second. The match starts at 15:00, and the majority of fans arrive in the 30 minutes before kick-off. What are the key infrastructure risks, and how should they be mitigated?
💡 Dica:Consider the authentication load profile and the impact of RADIUS server capacity on the user experience.
Mostrar Abordagem Recomendada
The primary risk is RADIUS server overload during the pre-match authentication surge. If 40,000 users attempt to authenticate in a 30-minute window, that is approximately 22 authentication requests per second on average — well within the 500 rps capacity. However, the arrival pattern will not be uniform: the peak surge in the final 5 minutes before kick-off could generate 5–10x the average rate, potentially exceeding 200 rps. Mitigations include: (1) deploying a load-balanced RADIUS cluster rather than a single server, with automatic failover; (2) configuring MAC Authentication Bypass (MAB) for returning devices, which bypasses the full authentication flow and significantly reduces RADIUS load for repeat visitors; (3) pre-caching the portal page on the wireless LAN controller to reduce portal controller load; (4) setting a short session timeout (e.g., 8 hours) so that devices that authenticated at a previous match do not consume RADIUS sessions unnecessarily; and (5) conducting a load test simulating the peak authentication rate before the first match day. Additionally, the portal page must be optimised for maximum performance — a slow-loading portal during a surge will cause users to abandon the login, reducing data capture rates and increasing support calls.
