Página de Aterragem WiFi vs. Splash Page: Qual é a Diferença?

Este guia de referência técnica clarifica as diferenças arquitetónicas e funcionais entre as páginas de aterragem WiFi e as splash pages — dois termos frequentemente confundidos tanto por equipas de TI como por departamentos de marketing. Fornece a arquitetos de rede, gestores de TI e diretores de operações de espaços estratégias de implementação acionáveis para otimizar o desempenho do Captive Portal, garantir a conformidade com o GDPR e PCI DSS, e maximizar o ROI em espaços empresariais, incluindo ambientes de hotelaria, retalho e setor público.

📖 8 min de leitura📝 1,923 palavras🔧 2 exemplos❓ 3 perguntas📚 9 termos-chave

🎧 Ouça este Guia

Ver Transcrição

Welcome back to the Purple Technical Briefing. Today we're tackling a question that comes up in almost every initial scoping call with CTOs and network architects: What exactly is the difference between a WiFi landing page and a splash page?

In the consumer world, people use these terms interchangeably. But when you're architecting an enterprise guest network across fifty retail locations, or a high-density stadium deployment, confusing the two can lead to compliance headaches, broken user journeys, and missed ROI.

So, over the next ten minutes, we're going to define the technical distinction, look at the architecture, discuss common implementation pitfalls, and finish with a rapid-fire Q and A. Let's get into it.

[SECTION: TECHNICAL DEFINITIONS]

First, let's define the terms. When we talk about a Captive Portal, we're referring to the entire walled-garden mechanism that intercepts HTTP and HTTPS traffic and forces a client device to authenticate before granting external network access.

Within that portal flow, the Splash Page is the gatekeeper. It is the very first screen a user sees when they connect to the SSID. Its primary technical function is authentication and authorisation. It's where the user accepts the Terms and Conditions, enters their credentials, or authenticates via an identity provider — perhaps using OAuth or a loyalty integration. From a compliance standpoint, this is where you handle GDPR consent and PCI DSS disclaimers if you're processing payments.

Now, contrast that with the Landing Page. The landing page is the destination after successful authentication. Once the RADIUS server sends the Access-Accept message and the client device is placed onto the active VLAN with internet routing, the walled garden drops. The controller then redirects the user's browser to the Landing Page.

Why does this distinction matter? Because the Splash Page exists in a highly constrained environment. The device doesn't have full internet access yet. It can only reach the specific IP addresses or hostnames you've whitelisted in your Walled Garden configuration. If you try to load heavy external scripts, dynamic video players, or complex third-party trackers on a splash page without proper whitelisting, the page will break, and the user gets stuck in a connection loop.

The Landing Page, however, sits on the open internet. The user is authenticated. Here, you can load full marketing experiences, dynamic app download links, interactive venue maps, and targeted promotions driven by the first-party data you just captured on the splash page.

[SECTION: IMPLEMENTATION AND PITFALLS]

Now let's talk about implementation and where I see deployments go wrong.

The most common mistake is overloading the Splash Page. I've seen marketing teams hand over a five-megabyte page with four different external tracking pixels and a background video, asking IT to make it the login screen.

When you do that, you have to add dozens of CDNs and third-party domains to your Walled Garden whitelist. Not only is this a nightmare to maintain as those IP ranges change, but it's a security risk. You are poking holes in your pre-authentication firewall. Furthermore, modern mobile operating systems — like iOS and Android — use a specialised mini-browser to render captive portals. These Captive Network Assistants, or CNAs, have limited functionality. They often block cookies, restrict local storage, and will automatically close if they detect external navigation before the internet connection is fully established.

The best practice? Keep the Splash Page lean, fast, and focused purely on data capture and legal consent. Use a cloud-based captive portal solution that optimises the HTML payload for these CNA browsers.

Once the user hits Connect, then redirect them to the rich, dynamic Landing Page. This is where you leverage your WiFi Analytics platform. Because you've already captured their profile, the Landing Page can be personalised. If they are a returning guest at your hotel, the landing page can welcome them by name and offer a one-click booking for the spa. If they are in a retail environment, it can show a heatmap-driven promotion based on their current zone.

[SECTION: CASE STUDIES]

Let me give you two concrete case studies that illustrate this perfectly.

First, a five-hundred-room hotel resort. They were experiencing high drop-off rates on their guest WiFi login. The marketing team had added a four-megabyte promotional video and a complex interactive map to the initial connection screen. The fix was straightforward: replace the connection screen with a lightweight Splash Page under one megabyte, focused solely on room number and last name authentication plus Terms and Conditions acceptance. The video and map were moved to the post-authentication Landing Page. Connection rates improved by over forty percent within the first week.

Second, a retail chain with fifty locations. They wanted to offer seamless WiFi access to returning loyalty members without forcing them to log in every time. The solution was MAC Authentication Bypass integrated with the loyalty database. When a returning device associates with the SSID, the controller queries the RADIUS server, identifies the MAC address, and immediately returns an Access-Accept without presenting the Splash Page. The user is redirected to a personalised Landing Page with their loyalty status and a targeted offer. The result: a thirty percent increase in loyalty app engagement across the estate.

[SECTION: RAPID-FIRE Q&A]

Now, let's move to our Rapid-Fire Q and A. These are the top three questions I get from network engineers.

Question one: Can I bypass the Splash Page entirely for returning users?

Yes. This is called MAC Authentication Bypass, or seamless login. The controller recognises the device's MAC address from a previous session and automatically authorises them, taking them straight to the Landing Page or their original destination. Just ensure your privacy policy covers persistent device tracking.

Question two: Why is my Splash Page showing a certificate error?

This usually happens when you try to intercept HTTPS traffic without a valid SSL certificate on the controller, or if you're using a self-signed certificate. Always use a publicly trusted certificate for your captive portal hostname, and ensure your controller supports modern HTTPS redirection standards like RFC 8908.

Question three: Should the Landing Page be hosted locally on the controller or in the cloud?

Always in the cloud. Hosting on the controller limits your ability to update content dynamically, run A/B tests, or integrate with external CRMs. A cloud-based architecture separates the network control plane from the user experience layer, which is exactly what enterprise deployments require.

[SECTION: SUMMARY AND NEXT STEPS]

To summarise: The Splash Page is the secure, constrained gatekeeper for authentication and consent. Keep it lightweight — under one megabyte, no external dependencies, optimised for the Captive Network Assistant. The Landing Page is the post-authentication destination for engagement, marketing, and ROI generation. It operates on the open internet with full browser capabilities.

Understand the constraints of the Walled Garden and the Captive Network Assistant, and you'll avoid ninety percent of the support tickets associated with guest WiFi deployments.

The three key rules to take away: Splash for Security, Landing for Loyalty. The Walled Garden is a sandbox, not a playground. And always — Authentication before Animation.

Thanks for joining this technical briefing. If you want to dive deeper into configuring cloud-based captive portals, check out the full reference guide on the Purple website. Until next time, keep your networks secure and your users connected.

Principais Conclusões

✓The Splash Page is the pre-authentication gatekeeper operating within the restricted Walled Garden — its sole purpose is identity verification and legal consent.
✓The WiFi Landing Page is the post-authentication destination operating on the open internet — its purpose is marketing engagement, personalisation, and ROI generation.
✓The Captive Network Assistant (CNA) renders the Splash Page in a sandboxed mini-browser that blocks cookies, restricts JavaScript, and limits external resource loading.
✓Overloading the Splash Page with marketing assets is the leading cause of guest WiFi connection failures and elevated support ticket volumes.
✓MAC Authentication Bypass (MAB) eliminates the Splash Page for returning devices, redirecting them directly to a personalised Landing Page — improving experience for repeat visitors.
✓A cloud-based captive portal architecture separates the network control plane from the user experience layer, enabling centralised management, dynamic content updates, and CRM integration.
✓Measurable ROI from guest WiFi is generated primarily through the Landing Page — via direct revenue attribution, loyalty engagement, and first-party data capture feeding into WiFi Analytics.

Resumo Executivo

Para as equipas de TI empresariais que gerem espaços de alta densidade — desde propriedades de Hotelaria a propriedades de Retalho — os termos "splash page" e "landing page" são frequentemente confundidos. Tratá-los como intermutáveis na arquitetura de rede leva a percursos de utilizador interrompidos, vulnerabilidades de segurança e oportunidades perdidas de captura de dados.

Num nível fundamental, a Splash Page é o guardião pré-autenticação. Existe dentro do ambiente restrito de um Walled Garden, sendo responsável pela verificação de identidade, autenticação MAC e consentimento legal ao abrigo do GDPR e PCI DSS. A WiFi Landing Page é o destino pós-autenticação. Opera na internet aberta, aproveitando os dados capturados durante o login para oferecer experiências personalizadas, impulsionar downloads de aplicações e gerar ROI mensurável através de integrações de Guest WiFi .

Este guia detalha as especificações técnicas, metodologias de implementação e modos de falha comuns associados ao design de Captive Portal — permitindo que os arquitetos de rede construam redes de acesso de convidados robustas, compatíveis e geradoras de receita em qualquer tipo de espaço.

Análise Técnica Detalhada

A Arquitetura do Captive Portal

Um Captive Portal interceta o tráfego HTTP/HTTPS de clientes não autenticados e redireciona-os para uma interface web designada. Este mecanismo baseia-se numa combinação de sequestro de DNS, redirecionamento HTTP 302 e autenticação RADIUS — com implementações modernas a adotar cada vez mais o RFC 8908 (Captive Portal Identification in DHCP and Router Advertisements) para permitir a descoberta nativa de Captive Portal ao nível do OS sem interceção HTTP frágil.

Dentro desta arquitetura, a Splash Page e a Landing Page desempenham papéis fundamentalmente diferentes em diferentes pontos do ciclo de vida da autenticação.

1. A Splash Page (Estado Pré-Autenticação)

Quando um dispositivo se associa a um SSID, o controlador wireless coloca-o numa VLAN não autenticada. Todo o tráfego de saída é intercetado e redirecionado para o nome de host do Captive Portal. O Captive Network Assistant (CNA) do sistema operativo — um pseudo-navegador especializado e isolado, integrado no iOS, Android e Windows — deteta o Captive Portal e renderiza a Splash Page.

Restrições Técnicas do Ambiente CNA:

O CNA não é um navegador completo. Opera com restrições significativas que impactam diretamente o que pode ser implementado numa Splash Page:

Cookies e armazenamento local são frequentemente bloqueados ou severamente limitados
Frameworks JavaScript complexos podem falhar na execução
Recursos externos (fontes, scripts, imagens) só podem ser carregados se os seus domínios estiverem na lista branca do Walled Garden
O CNA fechará automaticamente se detetar que o dispositivo obteve acesso à internet antes de o utilizador ter concluído a autenticação
A persistência da sessão após o fecho do CNA não é fiável

Funções Primárias da Splash Page:

Dadas estas restrições, a Splash Page deve ser projetada exclusivamente para: autenticação (login social via OAuth, SMS OTP, credenciais baseadas em formulário ou integração de programa de fidelidade); aceitação de Termos e Condições; captura de consentimento GDPR; e registo de endereço MAC para futuro login sem interrupções.

Recomendação de Payload: Mantenha a Splash Page abaixo de 1MB. Use CSS inline, evite bibliotecas de fontes externas e minimize o JavaScript. Cada dependência externa requer uma entrada correspondente na lista branca do Walled Garden — cada uma das quais representa tanto um encargo de manutenção como uma potencial exposição de segurança.

2. A Landing Page (Estado Pós-Autenticação)

Após a autenticação bem-sucedida, o servidor RADIUS retorna uma mensagem Access-Accept. O controlador wireless atualiza a sessão do cliente, migrando o dispositivo para uma VLAN autenticada com roteamento completo para a internet. O Walled Garden é desativado. O controlador — ou a plataforma de Captive Portal baseada na cloud — emite um redirecionamento HTTP 302 para a WiFi Landing Page.

Neste ponto, o dispositivo está a operar com um navegador completo e acesso irrestrito à internet. A Landing Page pode aproveitar o conjunto completo de capacidades do desenvolvimento web moderno:

Conteúdo dinâmico e personalizado impulsionado pelo perfil do utilizador capturado na Splash Page
Instrumentação analítica completa (Google Analytics, pixels de rastreamento personalizados, webhooks de CRM)
Rich media, incluindo vídeo, mapas interativos e dashboards de fidelidade
Pedidos de download de aplicações com roteamento de deep-link
Promoções direcionadas com base em dados de WiFi Analytics , incluindo frequência de visitas, tempo de permanência e zona do espaço

Funções Primárias da Landing Page: Engajamento de marketing, exibição de programa de fidelidade, promoções direcionadas, navegação no espaço e chamadas para ação orientadas para a conversão.

Fluxo de Autenticação: De Ponta a Ponta

A sequência abaixo ilustra o fluxo completo desde a associação ao SSID até à entrega da Landing Page:

O dispositivo cliente associa-se ao SSID de convidado
O controlador atribui o dispositivo a uma VLAN não autenticada
O cliente tenta um pedido HTTP; o controlador interceta e emite um redirecionamento 302 para a Splash Page
O CNA carrega a Splash Page (ativos servidos apenas de domínios na lista branca do Walled Garden)
O utilizador conclui a autenticação e aceita os Termos e Condições
A plataforma de Captive Portal envia um Access-Request para o servidor RADIUS
O RADIUS retorna Access-Accept; o controlador recebe uma mensagem Change of Authorization (CoA)
O controlador migra o cliente para a VLAN autenticada
A plataforma de Captive Portal emite um redirecionamento 302 para a WiFi Landing Page
O navegador do cliente carrega a Landing Page completa através da internet aberta

Esta clara separação de preocupações — autenticação ema Splash Page, o envolvimento na Landing Page — é a base arquitetónica de cada implementação de WiFi para convidados bem projetada.

Guia de Implementação

Implementar uma solução de WiFi para convidados escalável e de nível empresarial requer separar o plano de controlo da rede da camada de experiência do utilizador. Os passos seguintes fornecem uma estrutura de implementação neutra em relação ao fornecedor, aplicável em infraestruturas Cisco Meraki, Aruba, Ruckus e Ubiquiti.

Passo 1: Configuração do Walled Garden

Configure o seu Wireless LAN Controller (WLC) para permitir apenas os domínios e intervalos de IP estritamente necessários para o funcionamento da Splash Page. Isto tipicamente inclui:

O nome de anfitrião da plataforma Captive Portal (ex: portal.purple.ai)
Domínios de fornecedores de identidade para social login (ex: accounts.google.com, graph.facebook.com)
Domínios de gateway SMS se estiver a usar autenticação OTP
Quaisquer ativos CDN usados pela própria Splash Page

Evite a permissão excessiva. Cada entrada adicional aumenta a superfície de ataque da sua rede de pré-autenticação e complica a manutenção contínua à medida que os intervalos de IP mudam.

Passo 2: Gestão de Certificados SSL

Configure o WLC com um certificado SSL válido e publicamente confiável para o nome de anfitrião de redirecionamento do Captive Portal. Certificados autoassinados irão desencadear avisos de segurança do navegador no CNA, fazendo com que os utilizadores abandonem o processo de conexão. A expiração de certificados é uma das principais causas de interrupções de WiFi para convidados — implemente a renovação automatizada via Let's Encrypt ou a sua plataforma de gestão de certificados.

Passo 3: Otimização do CNA

Projete a Splash Page especificamente para o ambiente CNA. Use CSS inline, evite frameworks JavaScript externos e teste em várias versões de iOS e Android. O comportamento do CNA no iOS, em particular, muda entre as principais versões do SO — mantenha uma matriz de testes de regressão que cubra pelo menos as duas versões principais mais recentes de ambas as plataformas.

Passo 4: Lógica de Redirecionamento Pós-Autenticação

Configure o redirecionamento pós-autenticação para suportar URLs dinâmicos de Landing Page. O servidor RADIUS pode retornar atributos específicos do fornecedor (VSAs) ou a plataforma Captive Portal pode usar o perfil de utilizador autenticado para construir um URL personalizado. Isto permite a segmentação — um visitante pela primeira vez recebe uma oferta de boas-vindas, enquanto um membro de fidelidade com status Gold recebe um painel personalizado.

Passo 5: Integração de Análises

Instrumente a Landing Page com a sua pilha de análises. Como o utilizador está agora na internet aberta com um navegador completo, as ferramentas de análise padrão funcionam normalmente. Integre com o seu CRM para criar um perfil de cliente unificado que combine dados de sessão WiFi com histórico de compras, status de fidelidade e métricas de envolvimento de marketing.

Para uma comparação detalhada de arquiteturas de Captive Portal baseadas na nuvem versus no local, consulte Captive Portal Baseado na Nuvem vs. No Local: Qual é o Certo para o Seu Negócio? .

Melhores Práticas

Desacople Autenticação e Marketing. A decisão arquitetónica mais impactante é usar a Splash Page estritamente para acesso seguro e consentimento, e mover todos os ativos de marketing para a Landing Page. Isto melhora as taxas de conexão, reduz os tickets de suporte e simplifica as auditorias de conformidade.

Aproveite o MAC Authentication Bypass para Utilizadores Recorrentes. Para dispositivos recorrentes, o MAC Authentication Bypass (MAB) elimina a Splash Page por completo, redirecionando os utilizadores diretamente para uma Landing Page personalizada. Isto melhora drasticamente a experiência do utilizador para visitantes repetidos em ambientes de Hotelaria e Retalho . Certifique-se de que a sua política de privacidade cobre explicitamente o rastreamento persistente de dispositivos.

Adote Arquiteturas Centradas na Nuvem. Assim como a indústria de redes avançou para WAN definida por software para gestão centralizada — conforme detalhado em Os Principais Benefícios do SD WAN para Empresas Modernas — as plataformas de Captive Portal devem ser alojadas na nuvem. Isto permite a gestão centralizada em propriedades de locais distribuídos, atualizações rápidas de conteúdo sem alterações de firmware do controlador e integração perfeita com CRMs externos e plataformas de automação de marketing.

Implemente o RFC 8908 para Compatibilidade com SO Modernos. A deteção nativa de Captive Portal via RFC 8908 reduz a dependência da interceção HTTP, melhorando a fiabilidade em versões modernas de iOS e Android que cada vez mais impõem a navegação apenas por HTTPS.

Mantenha um Cronograma de Auditoria do Walled Garden. Reveja as entradas do Walled Garden trimestralmente. Os intervalos de IP para os principais fornecedores de identidade mudam sem aviso prévio. Entradas obsoletas que já não resolvem criam falhas de autenticação; entradas em falta bloqueiam fluxos de autenticação legítimos.

Resolução de Problemas e Mitigação de Riscos

O Ciclo de Conexão. Se um utilizador autentica mas é repetidamente redirecionado de volta para a Splash Page, verifique se a mensagem RADIUS Access-Accept está a chegar ao controlador e se o cliente está a receber com sucesso um lease DHCP na VLAN autenticada. Verifique também se a porta CoA (Change of Authorization) (UDP 3799) não está bloqueada por uma firewall intermédia.

Fecho Prematuro do CNA. Se o CNA fechar antes que o utilizador possa autenticar, o dispositivo provavelmente detetou acesso à internet prematuramente. Isto pode ocorrer se o Walled Garden for demasiado permissivo, permitindo inadvertidamente o encaminhamento completo da internet antes que a autenticação seja concluída. Reveja as entradas do Walled Garden para intervalos CIDR excessivamente amplos.

Erros de Interceção HTTPS. Os navegadores modernos impõem o HTTP Strict Transport Security (HSTS). Se um utilizador tentar navegar para um domínio pré-carregado com HSTS antes de autenticar, o navegador bloqueará o redirecionamento do Captive Portal. Implemente o RFC 8908 para ativar a descoberta nativa do Captive Portal, ou instrua os utilizadores a navegar para um domínio não-HSTS para acionar o CNA.

Falhas de Scripts de Terceiros na Splash Page. Se as equipas de marketing adicionaram pixels de rastreamento ou scripts de análise à Splash Page, estes falharão silenciosamente no ambiente CNA se os seus domínios não estiverem na lista de permissões. A resolução correta é remover estes scripts da Splash Page na totalidade e reimplantá-los na Landing Page, onde funcionarão corretamente.

Lacunas de Conformidade com o GDPR. Garanta que o mecanismo de consentimento na Splash Page cumpre os requisitos do Artigo 7 do GDPR — o consentimento deve ser dado livremente, ser específico, informado e inequívoco. Caixas de consentimento pré-selecionadas não são conformes. Mantenha um registo de auditoria de consentimento por um mínimo de três anos.

ROI e Impacto no Negócio

Uma arquitetura de Splash/Landing Page corretamente implementada transforma o WiFi de convidado de um centro de custos num ativo gerador de receita mensurável. O caso financeiro opera em três dimensões.

Captura de Dados e Inteligência de Primeira Parte. Ao otimizar a Splash Page, os locais aumentam as taxas de conexão e o volume de dados de primeira parte capturados. Em ambientes de Saúde e Transporte , estes dados apoiam a análise operacional — padrões de fluxo de pessoas, tempo de permanência por zona e previsão de pico de procura — permitindo decisões de alocação de recursos com poupanças de custos mensuráveis.

Atribuição Direta de Receita. A Landing Page é a principal superfície de conversão. Uma implementação em estádio pode usar a Landing Page para promover pedidos de comida e bebida no lugar, correlacionando diretamente o acesso à rede com a receita transacional. Um hotel pode oferecer reservas de spa ou upgrades de quarto. Um retalhista pode servir promoções específicas da zona impulsionadas por dados de localização em tempo real de WiFi Analytics .

Lealdade e Retenção. Experiências personalizadas na Landing Page — impulsionadas pelo perfil do utilizador capturado na Splash Page — aumentam o envolvimento com o programa de lealdade. Utilizadores que regressam e recebem uma experiência de boas-vindas personalizada demonstram uma duração de sessão e frequência de visitas repetidas significativamente maiores em comparação com utilizadores que recebem uma landing page genérica.

Os KPIs mensuráveis para uma implementação de WiFi de convidado devem incluir: taxa de conexão WiFi (alvo >70% dos visitantes do local), taxa de captura de dados (alvo >85% dos utilizadores conectados), taxa de cliques na Landing Page no CTA principal e receita direta atribuída a promoções impulsionadas por WiFi.

Ouça o podcast completo do briefing técnico abaixo:

Termos-Chave e Definições

Captive Portal

A web-based access control mechanism that intercepts network traffic from unauthenticated clients and redirects them to an authentication interface before granting broader network access.

The overarching system IT teams deploy to manage guest access, enforce acceptable use policies, capture user consent, and collect first-party data.

Splash Page

The initial authentication interface presented within the captive portal flow, operating within the restricted Walled Garden environment before the user has been granted internet access.

Where network architects must focus on lightweight design, identity verification, and legal consent. Incorrectly overloading this page with marketing assets is the leading cause of guest WiFi connection failures.

WiFi Landing Page

The post-authentication destination page loaded in the user's full browser after the device has been granted internet access by the RADIUS server.

Where marketing and operations teams deploy rich media, personalised content, loyalty integrations, and engagement campaigns. Operates without the constraints of the Walled Garden.

Walled Garden

A restricted network environment that allows unauthenticated users to access only a specific, explicitly whitelisted set of IP addresses or hostnames, blocking all other internet traffic.

The technical boundary within which the Splash Page must operate. Every external resource used by the Splash Page must have its domain or IP range added to the Walled Garden whitelist.

Captive Network Assistant (CNA)

A specialised, sandboxed pseudo-browser built into mobile operating systems (iOS, Android, Windows) that automatically detects and renders captive portal login pages.

The primary reason Splash Pages must be lightweight and avoid complex JavaScript, external cookies, or large media assets. CNA behaviour varies between OS versions and requires ongoing regression testing.

MAC Authentication Bypass (MAB)

A network access control technique that authenticates devices based on their hardware MAC address without requiring user interaction, enabling seamless login for returning devices.

Used to provide frictionless login experiences for returning guests or registered IoT devices. Requires integration between the RADIUS server and the venue's loyalty or device registry database.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol providing centralised Authentication, Authorisation, and Accounting (AAA) management for network access, defined in RFC 2865.

The backend server infrastructure that validates credentials submitted on the Splash Page, instructs the controller to grant access, and returns user attributes used to personalise the Landing Page.

RFC 8908

The IETF standard defining the Captive Portal API, enabling devices to discover and interact with captive portals natively through DHCP options and Router Advertisements rather than relying on HTTP interception.

A modern standard that improves captive portal reliability across iOS 14+ and Android 11+, reducing CNA-related connection failures caused by HTTPS interception issues.

Change of Authorization (CoA)

A RADIUS extension (RFC 5176) that allows the RADIUS server to dynamically modify an active network session — for example, migrating a client from an unauthenticated to an authenticated VLAN after successful login.

The mechanism by which the captive portal platform instructs the wireless controller to grant internet access after the user completes authentication on the Splash Page.

Estudos de Caso

A 500-room hotel resort is experiencing high drop-off rates on their guest WiFi login. The marketing team recently added a 4MB promotional video and a complex interactive venue map to the initial connection screen. Connection rates have dropped from 68% to 31% since the update. How should the network architect resolve this?

The architect must decouple the authentication and marketing functions. Step 1: Replace the current connection screen with a lightweight Splash Page under 1MB, containing only the authentication form (room number and last name), a GDPR-compliant consent checkbox, and Terms and Conditions acceptance. Step 2: Remove all external script dependencies from the Splash Page and serve all assets from the captive portal platform's own CDN, which is already whitelisted in the Walled Garden. Step 3: Configure the wireless controller's post-authentication redirection to send the user to a newly created Landing Page hosted on the open internet. Step 4: Move the 4MB promotional video and interactive venue map to this Landing Page. Step 5: Instrument the Landing Page with the hotel's CRM integration to personalise the welcome message based on the authenticated user profile. Step 6: Implement MAC Authentication Bypass for returning guests to eliminate the Splash Page entirely on subsequent visits.

Notas de Implementação: This approach resolves the drop-off issue by acknowledging the fundamental constraints of the Captive Network Assistant (CNA). The heavy assets were causing the CNA to time out or fail to render within the restricted Walled Garden environment. Moving them to the post-authentication Landing Page ensures they load correctly using the device's full browser capabilities over an established internet connection. The MAB implementation for returning guests further improves the experience for the hotel's most valuable repeat customers, while the CRM integration on the Landing Page creates a measurable revenue attribution pathway.

A retail chain wants to offer seamless WiFi access to returning loyalty programme members across 50 locations, bypassing the login screen while still displaying a personalised welcome offer and current loyalty points balance. What is the recommended technical architecture?

Implement MAC Authentication Bypass (MAB) integrated with the loyalty database via RADIUS. Architecture: (1) When a returning device associates with the SSID, the controller sends a RADIUS Access-Request containing the device MAC address. (2) The RADIUS server queries the loyalty database to match the MAC address to a loyalty profile. (3) If a match is found, the RADIUS server returns an Access-Accept with a vendor-specific attribute (VSA) containing a signed user token. (4) The controller grants immediate internet access and issues a redirect to the Landing Page URL, appending the signed token as a query parameter. (5) The cloud-hosted Landing Page decodes the token, queries the loyalty API for the user's current points balance and personalised offer, and renders a customised welcome experience. For new users or unrecognised devices, the standard Splash Page flow is presented, with an option to link the device to their loyalty account for future seamless access.

Notas de Implementação: This solution correctly utilises MAB for network access control while leveraging the Landing Page for the marketing requirement. The signed token approach prevents URL manipulation and ensures the personalised content is served only to the authenticated user. The fallback to the standard Splash Page for unrecognised devices ensures that new customer acquisition is not compromised. This architecture demonstrates a mature understanding of decoupled captive portal design and is directly applicable to enterprise retail deployments across distributed venue estates.

Análise de Cenários

Q1. A public sector organisation requires all guest WiFi users to accept a lengthy Acceptable Use Policy (AUP) before accessing the internet. The communications team also wants to display a dynamic feed of upcoming community events and a live social media wall. How should you architect this requirement across the captive portal flow?

💡 Dica:Consider the constraints of the Captive Network Assistant (CNA) and the Walled Garden when deciding where to place each content element.

Mostrar Abordagem Recomendada

Place the Acceptable Use Policy (AUP) on the Splash Page to ensure legal compliance before authentication. The AUP should be presented as inline text or a scrollable div — not loaded from an external URL — to avoid Walled Garden dependencies. Once the user accepts the AUP and is authenticated, redirect them to the Landing Page to display the dynamic community events feed and social media wall. The social media wall in particular requires external API calls that cannot function within the Walled Garden, making the Landing Page the only viable location.

Q2. During a new deployment at a conference centre, users report that the login screen appears correctly but when they click 'Sign in with LinkedIn', the page times out and returns an error. The controller configuration and RADIUS server are both functioning correctly for email/password authentication. What is the most likely cause and resolution?

💡 Dica:Think about what network access is required for a third-party OAuth identity provider to complete its authorisation flow during the pre-authentication phase.

Mostrar Abordagem Recomendada

The Walled Garden configuration is incomplete. LinkedIn's OAuth flow requires the client device to communicate with LinkedIn's authorisation servers (e.g., www.linkedin.com, api.linkedin.com) during the pre-authentication phase. These domains are not whitelisted, so the OAuth redirect fails. The resolution is to identify all IP ranges and hostnames used by LinkedIn's OAuth API and add them to the Walled Garden whitelist on the wireless controller. Note that LinkedIn (and other major identity providers) may use multiple CDN-hosted domains — review the OAuth documentation or use a packet capture to identify all required endpoints.

Q3. A retail client wants to track user behaviour on the initial WiFi login screen using Google Analytics 4 and a custom retargeting pixel from their advertising platform. The marketing team has provided a tag manager snippet to be added to the Splash Page. Why is this technically problematic, and what is the recommended alternative that preserves the marketing team's measurement requirements?

💡 Dica:Evaluate the capabilities of the CNA mini-browser and the implications of adding external script domains to the Walled Garden.

Mostrar Abordagem Recomendada

This is problematic for two reasons. First, the CNA often blocks cookies and restricts JavaScript execution, rendering client-side tracking scripts ineffective or unreliable. Second, Google Tag Manager and advertising pixels load scripts from multiple external domains — adding all of these to the Walled Garden creates significant security exposure and ongoing maintenance overhead. The recommended alternative is a two-part approach: (1) Capture the authentication event server-side via the captive portal platform's API or RADIUS accounting logs, and push this event to Google Analytics 4 using the Measurement Protocol (server-side), which does not require client-side JavaScript. (2) Deploy the full Google Tag Manager container and retargeting pixel on the post-authentication Landing Page, where the full browser environment ensures reliable script execution and cookie-based tracking functions normally.