跳至主要内容

自定义 Captive Portal:HTML 和 CSS 指南

本权威技术参考指南概述了设计和编码自定义 Captive Portal 登录页面所需的开发标准、CSS 架构和网络级限制。它为前端开发人员和网络架构师提供了切实可行的策略,以应对 Apple CNA 和 Android webview 环境,从而确保像素级完美、合规且高性能的访客 WiFi 体验。

📖 11 分钟阅读📝 2,731 🔧 2 应用实例3 练习题📚 8 关键定义

收听本指南

查看播客转录
自定义 Captive Portal:HTML 与 CSS 指南 —— Purple 技术简报 [INTRODUCTION] 欢迎来到 Purple 技术简报系列。今天我们将深入探讨影响每一个访客 WiFi 部署的关键环节 —— Captive Portal。具体来说,我们将讨论如何为自定义 Captive Portal 落地页编写干净、可靠的 HTML 和 CSS。 如果你曾连接到酒店的 WiFi,却看到一个加载失败的展示页面——缺少图片、无样式的文本,或者点击无响应的登录按钮——那么你已经体验到了当开发人员在不了解其运行环境限制的情况下构建 Portal 时会发生什么。今天,我们将确保这种事情不会发生在你身上。 本期简报面向前端开发人员、创意设计师以及网页开发人员,无论你是从头构建 Captive Portal,还是自定义现有模板。我们将介绍 HTML 结构、关键的 CSS 规则、连资深开发人员都会踩坑的 Apple CNA 微型浏览器限制,以及像 Purple 的 Portal 构建器这样的平台如何完全消除其中的大部分复杂性。 让我们开始吧。 [TECHNICAL DEEP-DIVE] 首先,让我们从网络层面来明确什么是 Captive Portal。当设备连接到需要身份验证的 WiFi 网络时,网络会拦截 HTTP 流量并将用户重定向到一个落地页。这就是 Captive Portal。用户会看到一个展示页面,并完成某项操作(例如输入邮箱、接受条款、通过社交账号登录),随后网络才会授予完整的互联网访问权限。 关键要理解的是这个页面是在哪里渲染的。在 iOS 设备上,它在 Apple 的 Captive Network Assistant(即 CNA)内部打开,这是一个精简版的 WebKit webview。它不是 Safari。它没有持久化的 cookie。它无法加载外部资源。它的 JavaScript 支持非常有限。而且一旦用户切换到其他应用,它就会立即关闭。在 macOS 上,CNA 以固定的 900 x 572 像素进行渲染。在 Android 上,现代设备使用 Chrome Custom Tabs,其功能要强大得多。Windows 10 会打开用户的默认浏览器。三星设备则使用 Samsung Internet。 这种平台碎片化是生产环境中 Captive Portal 出现故障的最大单一原因。开发人员在他们的 Android 手机上进行测试,一切看起来都很好,然后酒店里使用 iPhone 的客人们却看到了一个带有无样式文本的白屏。因此,让我们来谈谈如何进行防御性编码。 Captive Portal HTML 和 CSS 的黄金法则是:将页面视为没有互联网连接的情况来处理。因为在身份验证阶段,它确实没有连接。网络是受限的。您的页面尝试从外部 URL 加载的任何资源——无论是 Google Font、CDN 托管的样式表、JavaScript 库还是 Logo 图片——都会静默失败,或者导致加载动画永远无法完成。 首先是 HTML 结构。您的文档应该是一个干净的 HTML5 页面。在 head 中,您需要一个 viewport meta 标签,其 content 属性设置为 width=device-width 且 initial-scale=1。这对于移动端渲染是不可妥协的。如果没有它,iOS 将以 980 像素的宽度渲染页面并将其缩小,导致所有内容都变得微乎其微。 您的 CSS 必须是内联的——可以是在 head 元素内的 style 块中,也可以是单个元素上的内联 style 属性。不要使用通过 link 标签链接的外部样式表。该样式表驻留在您的服务器上,在身份验证期间,受限网络无法访问该服务器。页面渲染时将完全没有样式。 对于字体,请使用系统字体栈。例如:font-family — apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Helvetica Neue, Arial, sans-serif。这会告知浏览器使用任何可用的系统字体。不要使用 Google Fonts。导入调用将会失败,您的备选字体将变为 Times New Roman,而这并不是您的客户付钱想要获得的品牌体验。 对于图片(您的 logo、背景图形、装饰性元素),您有两个选择。要么从同一个 Captive Portal 服务器提供它们,这意味着它们位于同一个本地网络中,并且在身份验证完成之前即可访问。或者,更好的做法是直接在 HTML 或 CSS 中将它们编码为 Base64 data URI。这完全消除了外部依赖。 现在我们来谈谈页面布局。由于超过百分之九十的 Captive Portal 登录都发生在移动设备上,因此您的设计应该以移动端优先。这意味着采用单列布局,最大宽度约为 480 像素,并在页面居中。在 body 元素上使用 flexbox——display: flex, flex-direction: column, align-items: center, justify-content: center, min-height: 100vh。这可以在任何屏幕尺寸上将您的内容卡片在垂直和水平方向上居中。 您的主要行动呼吁按钮需要对触摸友好。Apple 的《人机界面指南》指定最小点击目标为 44 x 44 像素。在实践中,对于主要 CTA,您可能需要约 48 像素的高度、容器内的全宽,以及大约 8 到 12 像素的圆角。 对于表单字段(电子邮件输入、姓名输入),请将字号设置为至少 16 像素。这至关重要。iOS Safari 和 CNA 会自动放大任何字号低于 16 像素的输入框,这会破坏您精心设计的布局。将字号设置为 16 像素或以上可以防止这种缩放行为。 法律同意部分需要特别注意。在 GDPR 规定下,如果您正在收集个人数据(即使只是一个电子邮件地址),您也需要获得明确且知情的同意。这意味着默认情况下不勾选复选框,并带有可见的标签,清晰说明用户同意的内容。请勿预先勾选该复选框。同意复选框本身必须清晰可见,无需滚动即可看到。 现在,特别是针对 iOS CNA 的一个关键实现细节。当用户完成认证时,CNA 会监控 captive 域名是否已变得可访问。该检查由整页导航触发,而不是通过 JavaScript AJAX 调用。这意味着,如果您构建了一个单页应用,通过 fetch 或 XMLHttpRequest 提交表单并在不进行整页重定向的情况下更新 DOM,CNA 将永远无法检测到认证已完成。您必须在认证后重定向到一个新的 URL —— 这是完整的 HTTP 重定向,而不是 JavaScript DOM 操作。这是 Captive Portal 开发中最常见的错误之一。 对于 JavaScript,请保持其尽可能精简。CNA 的 JS 支持有限,且无法访问 localStorage 或 sessionStorage。当 CNA 关闭时,Cookie 会被销毁。任何依赖这些浏览器 API 的状态管理都将失败。原生 JavaScript 事件监听器没有问题。jQuery 是一个 30 KB 的外部依赖项,会导致加载失败。 [IMPLEMENTATION RECOMMENDATIONS AND PITFALLS] 让我为您提供实用的实现清单。第一:始终包含 viewport 元标记。第二:所有 CSS 均为内联,不使用外部样式表。第三:所有图像要么从 captive portal 服务器提供,要么进行 Base64 编码。第四:使用系统字体栈,不使用 Web 字体。第五:所有输入框的字体大小至少为 16 像素。第六:触控友好的点击目标,至少 44 x 44 像素。第七:单栏布局,最大宽度 480 像素。第八:认证时进行整页重定向,而不是 JavaScript 状态更新。第九:符合 GDPR 规范的同意复选框,默认不勾选。第十:在真实的 iOS 设备上使用实际的 captive 网络进行测试,而不是浏览器预览。 我在生产环境中最常看到的陷阱。第一:Google Fonts —— 移除导入,它会加载失败。第二:外部 JavaScript 库 —— Bootstrap、jQuery,任何 CDN 托管的脚本都会失败。第三:在外部样式表中声明的 CSS 变量 —— 它们必须包含在您的内联样式块中。第四:通过 URL 引用的背景图像 —— 请对其进行 Base64 编码。第五:没有进行认证后重定向的 AJAX 表单提交 —— CNA 将无法检测到认证已完成。 现在,让我们坦诚地谈谈自建与购买的选择。从头开始构建自定义 Captive Portal 意味着您还需要负责后端基础设施 —— RADIUS 服务器、数据库、SSL 证书、DNS 配置、与接入点的网络集成以及持续的安全补丁。这是一项重大的工程投入。 Purple 的 portal 生成器为您提供了一个拖拽式界面,并为需要像素级完美控制的开发者提供了自定义 HTML 和 CSS 编辑器,同时处理所有的后端基础设施 —— 认证、数据采集、数据分析、符合 GDPR 规范的工具,以及与 200 多家接入点厂商的网络集成。您无需承担基础设施开销即可获得创意控制权。 [RAPID-FIRE Q AND A] 我可以在 captive portal 中使用 CSS Grid 吗?可以,但请务必在 iOS CNA 上进行特定测试。Flexbox 在旧版 WebKit 版本中具有更广泛的支持。我可以使用 SVG 标志吗?可以,内联 SVG 得到完全支持,且比 Base64 编码的 PNG 更适合作为标志,因为它们在 retina 显示屏上能完美缩放。macOS CNA 是否支持与 iOS CNA 相同的限制?大致相同,但有一个区别:macOS CNA 会在固定的 900 x 572 像素窗口中渲染。我可以使用像 Tailwind 这样的 CSS 框架吗?只有在您生成一个经过清理、自包含的 CSS 文件并将其内联到样式块中时才可以。那 HTTPS 呢?您的 captive portal 必须通过 HTTP 提供服务,以便初始重定向正常工作——受管网络(captive network)无法拦截 HTTPS 连接。 [总结与后续步骤] 总结一下今天的简报。自定义 captive portal 是一个受限的网页环境,而不是标准的浏览器上下文。Apple CNA 和 Android webview 对外部资源、Cookie、JavaScript 和会话状态施加了严格的限制。解决方案是构建自包含的 HTML 页面,其中包含内联 CSS、系统字体、Base64 编码的图像,并在身份验证时进行全页重定向。 对于评估选择的场所运营商和 IT 团队:如果您的需求是具有自定义 HTML 和 CSS 的完全品牌化、定制化门户,那么您需要在自己构建和维护整个技术栈(这是一项重大的工程投入)与使用像 Purple 这样在生产级后端基础设施之上提供自定义 HTML 和 CSS 编辑功能的平台之间做出选择。 接下来的步骤:查阅 Purple 的门户编辑器文档,根据我们今天介绍的移动优先清单审计您现有的门户,如果您是从头开始,请使用我们概述的 HTML 模板结构作为基准。感谢您的收听,我们下期简报再见。

📚 核心系列的一部分:Captive Portal 终极指南

header_image.png

Executive Summary

For enterprise venues—ranging from luxury hotels Hospitality and retail chains Retail to transit hubs Transport and modern medical campuses Healthcare —the guest WiFi splash page is the digital front door. However, over 90% of guest WiFi logins occur on mobile devices, where rendering is governed not by standard browsers like Safari or Chrome, but by highly restricted Captive Network Assistant (CNA) webviews [1]. These "mini-browsers" enforce severe sandbox limitations: they block external CDNs, disable persistent cookies, ignore external web fonts, and severely restrict JavaScript execution to mitigate security risks and prevent session hijacking [2].

When a developer designs a splash page using traditional web standards, these constraints result in broken layouts, missing brand assets, and non-functional login buttons, directly impacting customer satisfaction and digital engagement. This guide provides solutions to these challenges, presenting defensive coding practices—such as inline CSS, Base64 asset encoding, system font stacks, and explicit navigation-driven authentication handshakes—to ensure seamless cross-platform rendering. Furthermore, we examine how utilising a managed solution like Purple's portal builder allows developers to maintain complete HTML/CSS creative control while offloading RADIUS authentication, database scaling, GDPR/PCI compliance, and multi-vendor AP integrations [3].

Technical Deep-Dive

To build a resilient custom captive portal, developers must understand the network-level interception and browser virtualisation that occurs when a guest associates with an open Service Set Identifier (SSID).

The Captive Portal Lifecycle

When a client device associates with a captive SSID, the following sequence is triggered:

  1. IP Association: The device completes a 3-way handshake and requests an IP address via DHCP.
  2. Active Connectivity Probe: The operating system's background network manager immediately sends an HTTP GET request to a dedicated vendor-neutral canary URL (e.g., Apple's http://captive.apple.com/hotspot-detect.html or Google's http://connectivitycheck.gstatic.com/generate_204) [1].
  3. DNS/HTTP Interception: The local Wireless LAN Controller (WLC) or Access Point (AP) intercepts this port 80 HTTP request. Instead of returning the expected HTTP 200 or 204 status, the gateway redirects the client's traffic to the captive portal's landing page URL via an HTTP 302 redirect [2].
  4. Webview Spawning: Detecting the redirect, the OS spawns its native Captive Network Assistant (CNA) mini-browser to display the redirected splash page, bypassing the need for the user to manually open a full browser.
  5. Authentication and State Transition: The user completes the login form, submitting credentials back to the portal server, which instructs the gateway (often via a RADIUS Access-Accept or external API call) to authorise the MAC address.
  6. CNA Exit Handshake: The CNA mini-browser performs another HTTP GET to its canary URL. If it receives the expected 200/204 response, it changes its top-right button from "Cancel" to "Done" and establishes the WiFi connection as the primary network interface.

Platform-Specific Mini-Browser Constraints

Each operating system handles this lifecycle within different webview environments, resulting in highly fragmented behaviour. The table below details these critical constraints:

Platform / Webview Display Method Persistent Cookies External Web Fonts JavaScript Execution Window Dimensions Exit Handshake Trigger
Apple iOS CNA (Websheet) Mini-Browser Popup Blocked (Destroyed on close) Blocked (Offline) Limited (No localStorage/sessionStorage) Responsive (Device-width) Full-page HTTP Redirect Only [1]
Apple macOS CNA (Captive Network Assistant) Mini-Browser Popup Blocked Blocked Limited (No alert/confirm dialogs) Fixed (900px x 572px) Full-page HTTP Redirect Only
Android (Google) (CaptivePortalLogin) Push Notification -> Chrome Custom Tab Allowed (Shared with Chrome) Allowed (If whitelisted in walled garden) Full Responsive Automatic (Captive Portal API / 204 Check) [2]
Samsung Android (Samsung Internet) Push Notification -> Mini-Browser Allowed Allowed Full Responsive Automatic
Windows 10/11 (Default Browser) Auto-Launch Default Browser Allowed (Full browser context) Allowed Full Responsive Manual / Automatic

cna_constraints_comparison.png

Coding Around the Apple CNA "Done" Button Trap

One of the most frequent failure modes in custom portal development is the "Done" Button Trap on iOS devices. When a user authenticates, the iOS Websheet webview must detect that the network is no longer captive. It does this by monitoring the success of its background canary requests.

Crucially, the iOS CNA will only trigger this check upon a full-page HTTP navigation (location redirect). If a developer builds a modern Single Page Application (SPA) that submits form data via an asynchronous AJAX call (e.g., fetch() or Axios) and updates the DOM dynamically without changing the URL, the CNA will never re-run its connectivity check. The user will be authenticated at the gateway level, but the CNA button in the top-right corner will remain as "Cancel". If the frustrated user clicks "Cancel", the iOS device will immediately disassociate from the SSID, terminating the WiFi session [1].

To prevent this, the authentication success handler must perform a full-page redirect to a physical landing page (e.g., window.location.href = '/success') or submit the login form natively via a standard HTTP POST action.

Implementation Guide

To ensure consistent rendering across all platforms, developers must transition from modern, asset-heavy web design to a highly self-contained, defensive coding style.

The Golden Rule: Design for Zero Internet Connectivity

During the captive state, the client device has no access to the wider internet. It can only resolve and access IP addresses and domains explicitly whitelisted in the wireless controller's Walled Garden (such as the IP of the captive portal server itself). Therefore, any external asset referenced in your HTML will fail to load, resulting in a broken layout.

To design defensively, implement the following Mobile-First Captive Portal Design Checklist:

mobile_first_checklist.png

1. Viewport Configuration

To prevent mobile devices from scaling down the viewport to a desktop width (typically 980px), the HTML `` must include a responsive viewport meta tag. Without this, text and input fields will appear microscopic on mobile devices:


2. Inlining CSS and Removing External Dependencies

Never link to external CSS files or CDNs (e.g., Bootstrap, Tailwind, or Google Fonts). All CSS must be embedded within a `

<div class="portal-card">
    <div class="logo-container">
        
        
            
            YOUR BRAND
        
    </div>
    
    <h1>Welcome to Guest WiFi</h1>
    <p>Please enter your details below to gain secure, high-speed internet access.</p>
    
    
    
        <div class="form-group">
            Full Name
            
        </div>
        
        <div class="form-group">
            Email Address
            
        </div>
        
        <div class="consent-group">
            
            
                I accept the <a href="#">Terms of Service</a> and consent to data processing in compliance with GDPR regulations.
            
        </div>
        
        <div id="terms_box" class="terms-scrollbox">
            <strong>WiFi Terms of Service:</strong><br />
            1. This service is provided as-is without warranties.<br />
            2. Users must not engage in illegal bandwidth-intensive activities.<br />
            3. Personal data is collected solely for authentication and marketing opt-ins in compliance with our Privacy Policy.
        </div>
        
        Connect to WiFi
    
    
    <div class="footer">
        Powered by Purple | Secure Guest WiFi
    </div>
</div>

## Troubleshooting &amp; Risk Mitigation

When deploying custom-coded HTML/CSS captive portals, IT operations teams frequently encounter several severe operational risks:

### 1. The SSL/TLS Certificate Warning Loop

Because captive portals function by intercepting traffic, they present a fundamental conflict with modern HTTPS web security. When a user attempts to visit an HTTPS site (e.g., `https://www.google.com`), and the gateway attempts to redirect that traffic to an HTTP captive portal, the browser detects a mismatch in the SSL certificate and displays a critical "Your connection is not private" security warning. 

* **Mitigation**: Never attempt to intercept HTTPS traffic directly. Rely entirely on the operating system's native CNA helper (which makes an unencrypted HTTP request to trigger the redirect). Ensure your captive portal's domain has a valid, publicly trusted SSL certificate (e.g., Let's Encrypt or DigiCert) and is served over HTTPS *only after* the initial HTTP redirect has successfully routed the user to your portal domain [2].

### 2. DNS Resolution Failures (The Walled Garden Trap)

If your custom HTML page references external resources—such as a social login OAuth endpoint (e.g., Facebook, Google) or a payment gateway—the DNS requests for these domains will fail unless they are explicitly whitelisted in the wireless controller's Walled Garden. If a domain is missing from the whitelist, the login flow will stall, presenting a blank screen.

* **Mitigation**: Maintain a strict, minimal Walled Garden list. If utilising social logins, whitelist the specific wildcard domains recommended by the identity providers (e.g., `*.google.com`, `*.gstatic.com`). 

### 3. Session Timeout and MAC Spoofing Vulnerabilities

Standard captive portals authenticate devices based on their MAC addresses. However, modern mobile operating systems (iOS 14+ and Android 10+) utilise randomised MAC addresses (private WiFi addresses) by default, rotating them periodically. This can lead to guests being repeatedly prompted to re-authenticate, destroying the user experience [1].

* **Mitigation**: Implement reasonable session timeouts (e.g., 24 hours) on the RADIUS server to prevent stale sessions, and utilise modern authentication standards like **Passpoint (Hotspot 2.0)** or **WPA3-Enterprise** for seamless, secure onboarding that bypasses MAC-based captive portals entirely.

## Purple Product Relevance: Build vs. Buy

While coding a single HTML page is straightforward, hosting, securing, and scaling a custom captive portal infrastructure presents massive technical and compliance hurdles. The table below compares the engineering and operational realities of self-hosting a custom portal versus utilising Purple's managed enterprise platform:

| Feature / Operational Requirement | Self-Hosted Custom Portal | Purple Enterprise WiFi Platform |
| :--- | :--- | :--- |
| **HTML/CSS Customisation** | Fully manual coding, uploading files to individual APs or local web servers. | **Pixel-perfect developer editor** allowing custom HTML/CSS injects, combined with a drag-and-drop visual builder.
| **RADIUS Infrastructure** | Must deploy, configure, and maintain highly available FreeRADIUS or Cloud RADIUS servers [4]. | **Built-in, globally distributed, cloud-native RADIUS** with active-active redundancy and 99.99% uptime SLAs.
| **Multi-Vendor AP Support** | Custom integration scripts required for each hardware vendor (Cisco, Aruba, Meraki, Ruckus) [5]. | **Native, out-of-the-box integration** with over 200 hardware models; unified portal deployment across mixed-hardware estates.
| **Data Privacy &amp; Compliance** | Venue assumes 100% legal liability for GDPR, CCPA, and PCI DSS compliance, including secure database encryption and data deletion workflows. | **Fully compliant by design**. Built-in consent management, automated data-subject deletion requests, and secure ISO 27001-certified hosting.
| **Analytics &amp; Marketing** | Requires building custom data ingestion pipelines and integrating third-party marketing tools. | **Enterprise-grade analytics dashboard** with real-time footfall tracking, return-rate metrics, and automated marketing campaign triggers [6].
| **Identity Provider Integrations** | Manual OAuth2 integrations with Google, Facebook, Apple, and local SMS gateways. | **One-click integrations** with major social platforms, SMS gateways, and Azure AD / Okta for corporate guests.

Purple's platform resolves the "Build vs. Buy" dilemma. It provides developers with the complete creative freedom of a custom HTML/CSS workspace while eliminating the complex, high-risk backend infrastructure engineering required to support secure RADIUS authentication at scale.

## ROI &amp; Business Impact

Investing in a professionally engineered, responsive custom captive portal delivers quantifiable returns across IT operations, marketing, and legal compliance.

### 1. Operational Cost Reduction (IT Helpdesk Tickets)

In large-scale deployments, such as a stadium or multi-site retail chain, a broken captive portal is a leading driver of IT helpdesk escalations. When guests encounter a "white screen" or a non-responsive login button, they overwhelm on-site staff or submit support tickets.

$$\text{Annual Support Savings} = (\text{Total Annual Guest Visits} \times \text{Portal Failure Rate} \times \text{Helpdesk Contact Rate}) \times \text{Cost Per Support Ticket}$$

* **Scenario**: A convention centre with 1,000,000 annual visitors. A poorly coded portal has a 5% failure rate on older iOS devices, leading to a 10% helpdesk contact rate. At an industry-standard $15 per support ticket, the operational cost is:
  $$(1,000,000 \times 0.05 \times 0.10) \times \$15 = \$75,000 \text{ annually in avoidable support overhead}$$
* **Outcome**: Transitioning to a CNA-optimised, mobile-first template reduces the portal failure rate to &lt;0.1%, virtually eliminating this operational drain.

### 2. Marketing Data Capture and Opt-in Optimisation

For retail and hospitality venues, the guest WiFi portal is the primary mechanism for capturing clean, first-party customer data. A poorly designed user interface with microscopic text or a clunky form layout causes high **bounce rates**—users abandon the login process entirely, resulting in lost marketing opportunities.

* **Case Study (Retail)**: A national retail chain implemented a mobile-first optimised captive portal utilising Purple's platform. By replacing a multi-step login form with a single-field email input (font-size: 16px) and an optimised 48px tap-target button, they saw a **42% increase in completed registrations** and a **28% increase in marketing newsletter opt-ins** within the first quarter [6].

### 3. Legal and Regulatory Risk Mitigation

Under GDPR and CCPA, non-compliant data collection carries severe financial penalties (up to 4% of global annual turnover under GDPR). Relying on pre-ticked checkboxes or failing to provide a clear, easily accessible Privacy Policy on your splash page exposes the enterprise to immense legal liability.

* **Mitigation ROI**: Implementing an explicit, un-ticked consent checkbox and hosting terms within an optimised scrollbox ensures 100% regulatory compliance, mitigating the risk of multi-million dollar regulatory fines and protecting brand reputation.

## Summary of Key Takeaways

* **The CNA Sandbox is Restrictive**: Apple's iOS Websheet and macOS CNA are highly sandboxed environments that block external assets, cookies, and web fonts. All styling and assets must be self-contained (inline CSS, Base64 images, system fonts) [1].
* **AJAX Breaks the iOS Exit Handshake**: To successfully transition the iOS device from "captive" to "connected" (changing the top-right button from "Cancel" to "Done"), you must trigger a full-page HTTP redirect. Asynchronous DOM updates will leave the device in a captive loop.
* **Mobile-First is Mandatory**: Over 90% of logins occur on mobile. Design a single-column layout (max-width: 480px), utilise touch-friendly tap targets (minimum 44px x 44px), and enforce a minimum 16px font size on all text inputs to prevent automatic iOS browser zooming.
* **Walled Gardens Control DNS**: Any external domain referenced during login (e.g., social login APIs) must be explicitly whitelisted in the wireless controller's walled garden, or the page will fail to load.
* **Purple Eliminates Backend Complexity**: Utilising Purple's portal builder gives developers complete HTML/CSS control via a custom editor, while offloading the immense security, scaling, and compliance burdens of RADIUS, multi-vendor AP integrations, and GDPR-compliant database management [3].

## References

* [1] [Wireless Broadband Alliance: Captive Network Portal Behaviour](https://captivebehavior.wballiance.com/)
* [2] [Android Open Source Project: Captive Portal Login Webview Integration](https://source.android.com/docs/core/connect/android-custom-tabs-captive-portal)
* [3] [European Data Protection Board: Guidelines on Consent under Regulation 2016/679](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en)
* [4] [How to Implement 802.1X Authentication with Cloud RADIUS](/guides/implementing-8021x-with-cloud-radius)
* [5] [Cisco Wireless APs: 2026 Guide to Products &amp; Deployment](/blog/cisco-wireless-ap)
* [6] [Purple WiFi Marketing &amp; Analytics Platform](/guest-wifi-marketing-analytics-platform)

---

## Listen to the Technical Briefing

Listen to a senior solutions architect discuss the technical constraints and implementation strategies for custom captive portals:

关键定义

Captive Portal

在向 Wi-Fi 网络的新连接用户授予更广泛的网络资源访问权限之前,向其展示的网页,通常用于身份验证、支付或显示服务条款。

IT 团队在网关级别部署 Captive Portal,以控制访客访问、捕获用户数据并强制执行法律合规性。

Captive Network Assistant (CNA)

一种高度受限的沙盒化微型浏览器,由操作系统(例如 Apple iOS 和 macOS)在检测到 Captive Portal 重定向时自动生成,其唯一目的是促进门户身份验证。

CNA Web 视图执行严格的限制,包括阻止外部 CDN、持久性 Cookie 和本地存储,这经常会破坏标准的网页设计。

Walled Garden

一个受限的 IP 地址、子网或域名列表,未经验证的访客用户在完成 Captive Portal 登录流程之前,允许通过网关访问这些资源。

开发人员必须确保将任何外部资源(例如社交登录 API 或支付网关)列入 Walled Garden 白名单,以防止登录流程停滞。

Base64 编码

一种二进制到文本的编码方案,将二进制数据(如图像)表示为 ASCII 字符串,允许将资产直接嵌入到 HTML 或 CSS 文档中。

利用 Base64 编码来处理徽标和图标可以消除外部 HTTP 请求,从而确保资产在离线 CNA 环境中完美呈现。

RADIUS (Remote Authentication Dial-In User Service)

一种网络协议,为连接和使用网络服务的用户提供集中的身份验证、授权和计费 (AAA) 管理。

一旦满足身份验证标准,Captive Portal 服务器就会与 RADIUS 服务器进行通信,以在网络网关处授权访客的 MAC 地址。

System Font Stack

一种 CSS font-family 声明,它将预安装的操作系统字体(例如 iOS 上的 San Francisco、Windows 上的 Segoe UI 和 Android 上的 Roboto)的优先级置于外部 Web 字体之上。

实现系统字体栈可确保立即渲染排版,而不会触发对 Google Fonts 等服务的被阻止的外部 HTTP 请求。

Canary URL

由操作系统供应商维护的专用、未加密的 HTTP URL(例如 captive.apple.com),用于测试设备是否具有不受限制的互联网连接。

操作系统后台网络管理器会检查此 URL,以检测是否存在 Captive Portal 并触发 CNA 网页视图弹出窗口。

Passpoint (Hotspot 2.0)

由 Wi-Fi Alliance 开发的行业标准,使移动设备能够自动发现 Wi-Fi 热点并与其进行安全身份验证,从而绕过手动 Captive Portal 登录。

企业将 Passpoint 与 Purple 等平台结合使用,使访客能够从繁琐的欢迎页面过渡到无缝的、类似于蜂窝网络的安全漫游体验。

应用实例

一家拥有 250 间客房的奢华连锁酒店 [Hospitality](/industries/hospitality) 希望实施自定义的访客 WiFi 登录页面,以完美契合其高端品牌指南。他们的创意代理商设计了一个过渡页面,利用了自定义品牌排版(托管在 Adobe Fonts 上)、多个高分辨率背景图像(托管在公共 AWS S3 存储桶中)以及一个多步骤动画 JavaScript 向导。部署后,iOS 访客连接到 SSID,但 Captive Portal 弹出为一个空白的白色屏幕,且用户无法进行身份验证。

要解决白屏和品牌展示失效的问题,我们必须重构该门户的前端架构,以符合 Apple CNA 沙盒限制:

  1. 排版修复:由于 Adobe Fonts 需要外部 HTTP 请求,该请求会被 CNA 拦截,因此我们使用原生、高端的系统字体库(font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Helvetica, Arial, sans-serif;)替换自定义字体调用。这确保了无需外部网络调用即可进行即时渲染。
  2. 资产优化:AWS S3 上的背景图像被拦截,因为 S3 不在网关的围墙花园内。我们压缩主品牌 Logo,将其转换为轻量级 SVG,并将其直接作为 Base64 Data URI 编码在 HTML 中。对于背景,我们使用符合酒店品牌颜色的整洁、响应式 CSS 渐变代替笨重的图像,从而显着减轻页面权重。
  3. JavaScript 简化:多步骤动画向导依赖外部 jQuery 和 GSAP 库。我们剥离这些外部依赖项,并将表单重构为单页、单栏 HTML 结构。表单验证使用轻量级原生 JavaScript 重写。
  4. 身份验证握手:表单提交从基于 AJAX 的提交修改为原生 HTML <form action="/submit" method="POST">,以触发全页重定向,从而允许 iOS Websheet 执行其 Canary 测试并显示“完成”按钮。
考官评语: 此场景代表了高端创意设计与 Captive Webview 严格安全限制之间的经典冲突。创意代理商通常将 Captive Portal 视为标准的桌面网站。然而,由于设备处于未通过身份验证的状态,网络会拦截所有外部流量。通过内联 CSS、系统字体库、Base64 编码资产以及利用原生表单提交,我们在保持高端品牌美学的同时,在 iOS 和 Android 设备上实现了 100% 的运行可靠性。

一家拥有 450 家门店的全国性零售连锁店 [Retail](/industries/retail) 希望通过 WiFi 过渡页面捕获访客电子邮件以填充其 CRM。他们要求访客选择同意接收营销简报。初始设计包含一个预先勾选的“我同意接收营销电子邮件”复选框。此外,该门户托管在其总部的单个本地服务器上。在高峰时段(周六下午),全国各地的访客都遇到了严重延迟,许多人无法加载登录页面,导致数据捕获率大幅下降。

我们必须同时解决合规性违规和基础设施瓶颈问题:

  1. 合规性修复:根据 GDPR 和 CCPA,预先勾选的同意框是非法的。我们修改 HTML,使营销同意复选框默认不勾选(<input type="checkbox" id="marketing_consent">)。我们还为服务条款添加了一个单独的必填复选框,以将法律协议与营销选择性同意进行解耦。
  2. 基础设施扩展:在单个集中式服务器上托管全国性 Captive Portal 会造成单点故障和巨大的延迟瓶颈。我们将门户前端迁移到具有边缘缓存的高可用、全球分布式内容分发网络(CDN)。
  3. RADIUS 集成:我们配置本地门店接入点,使其指向具有双活冗余的云原生 RADIUS 集群,确保即使在周六高峰流量期间,身份验证请求也能在边缘进行本地处理,且延迟低于 50 毫秒。
  4. Purple 迁移:为了消除这整项工程开销,该零售商迁移到了 Purple。Purple 内置的 GDPR 同意工具可自动管理合规的选择性同意,其全球分布的云基础设施可以处理每日数百万次的身份验证,并保证 99.99% 的在线率,从而彻底解决扩展瓶颈。
考官评语: 预先勾选的同意复选框代表了严重的合规风险,可能导致巨额监管罚款。将营销同意与服务条款解耦是一项技术和法律上的最佳实践。在基础设施方面,集中托管 Captive Portal 是一种反模式。全国性的零售业务版图需要分散式、边缘缓存的前端,并结合云原生 RADIUS 后端。迁移到像 Purple 这样的托管平台可以消除这种架构复杂性,使零售商能够专注于营销活动,而不是数据库扩展。

练习题

Q1. An IT team at a major international airport [Transport](/industries/transport) deploys a custom-coded captive portal. They notice that while Android users connect seamlessly, a significant portion of iOS users experience an issue where they authenticate successfully but cannot browse the web. On closer inspection, the iOS devices show they are connected to the SSID, but the top-right button on the captive popup still says 'Cancel' instead of 'Done'. What is the root cause of this issue, and how should the developer fix it?

提示:Analyze how the Apple CNA helper detects that a network has transitioned from captive to authenticated, and what browser action is required to trigger this check.

查看标准答案

The root cause is that the portal's success page is updating the UI dynamically via JavaScript (AJAX/SPA routing) rather than performing a full-page HTTP navigation. The Apple iOS Captive Network Assistant (CNA) mini-browser only re-runs its background connectivity check (the canary request to captive.apple.com) when a full-page URL redirect or navigation occurs. If the developer submits the login form via AJAX and simply displays a 'Success' message in the DOM, the CNA remains unaware that the network has been unlocked. Consequently, the top-right button remains as 'Cancel'. If the user clicks 'Cancel' to exit, the OS assumes the login failed and disconnects from the WiFi network.

Solution: The developer must modify the authentication success handler to force a full-page redirect. This can be achieved by submitting the login form natively via a standard HTML <form action="/submit" method="POST"> or by executing window.location.href = '/success_landing_page' in JavaScript once the API returns a successful authentication response. This triggers the required full-page load, forcing the CNA helper to re-evaluate the network state, verify that the canary URL is now reachable, and change the top-right button to 'Done'.

Q2. A stadium operations team [Events] wants to launch a guest WiFi network that captures marketing opt-ins. The compliance officer insists that the portal must be 100% GDPR-compliant. The development team presents a mockup where the login form has a pre-checked box saying 'I agree to the Terms of Service and consent to receive marketing newsletters'. Why is this design non-compliant, and how should the HTML/CSS and form structure be refactored to satisfy GDPR while maintaining a high conversion rate?

提示:Consider GDPR's strict requirements regarding explicit consent, the decoupling of marketing opt-ins from terms of service, and the physical visibility of legal text on mobile screens.

查看标准答案

The proposed design violates GDPR on two major fronts: first, pre-checked checkboxes do not constitute valid consent, which must be freely given, specific, informed, and unambiguous. Second, bundling marketing consent with the agreement to the Terms of Service is non-compliant; a user cannot be forced to accept marketing emails as a condition of using the WiFi service.

Refactoring Strategy:

  1. Decouple Consent: Split the checkbox into two separate checkboxes. Checkbox A is mandatory and covers the Terms of Service and Privacy Policy. Checkbox B is optional and covers marketing newsletter opt-in.
  2. Set to Unchecked: Ensure both checkboxes are unchecked by default in the HTML (checked attribute omitted).
  3. CSS Visibility: Since over 90% of users are on mobile, place the checkboxes directly above the 'Connect' button so they are visible 'above the fold' without scrolling. Use a system font stack and set the label font size to 14px with a line-height of 1.4 for readability.
  4. Terms Scrollbox: To prevent the legal text from pushing the form elements off the screen, place the detailed Terms of Service in a scrollable container with a fixed height (max-height: 100px; overflow-y: auto; background-color: #F5F1ED; border: 1px solid #D1D5DB; border-radius: 6px;) that can be toggled open or closed via a text link. This maintains a clean, high-converting layout while ensuring absolute legal compliance.

Q3. A retail chain [Retail](/industries/retail) is deploying a custom-coded splash page across 100 stores. The designer used Google Fonts (Montserrat) and linked to a CDN-hosted Bootstrap stylesheet in the HTML head. During testing on a corporate network, the page renders beautifully. However, when deployed on a test store AP with a captive network configuration, the page renders with unstyled Times New Roman text, broken alignment, and missing icons. Why does this happen, and how must the assets be refactored?

提示:Analyze the state of the network connection before a user is authenticated, and determine how the browser handles external HTTP requests to domains outside the walled garden.

查看标准答案

This failure occurs because the device is in an unauthenticated, captive state when the splash page is loaded. In this state, the wireless gateway blocks all outbound internet traffic, allowing requests only to domains explicitly whitelisted in the gateway's Walled Garden. Because the CDN domains for Bootstrap (cdn.jsdelivr.net) and Google Fonts (fonts.googleapis.com) are not whitelisted, the browser's requests to fetch the stylesheet and font files fail silently. Consequently, the browser falls back to its default rendering engine, resulting in unstyled HTML (Times New Roman text) and broken layouts.

Refactoring Strategy:

  1. Inline CSS: Remove the external Bootstrap stylesheet link. Copy the necessary CSS grid/flexbox rules directly into a <style> block in the HTML <head>. This ensures that all layout instructions are delivered in the initial single-page payload.
  2. Implement System Font Stack: Remove the Google Fonts @import or <link> call. Replace it with a native system font stack in the CSS (font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;). This forces the device to use high-quality fonts already pre-installed on the operating system, eliminating the external network dependency entirely.
  3. Base64 Encode Icons/Logos: If the layout relies on external images or icon libraries (like FontAwesome), convert these icons into SVG format and embed them inline within the HTML or as Base64 Data URIs in the CSS. This guarantees that the page is 100% self-contained and renders perfectly even with zero internet connectivity.