Comment créer une page de connexion WiFi personnalisée pour votre marque
Ce guide fournit une référence complète et prête à l'emploi pour les responsables informatiques, les architectes réseau et les directeurs d'exploitation de sites sur la façon de créer une page de connexion WiFi invité entièrement personnalisée — couvrant l'architecture du Captive Portal, la personnalisation HTML/CSS, la conformité GDPR et la stratégie de capture de données. Il passe des fondations techniques aux scénarios de déploiement réels dans l'hôtellerie et le commerce de détail, avec des résultats commerciaux mesurables à chaque étape. Pour les organisations utilisant la plateforme WiFi invité de Purple, le guide correspond directement aux capacités de création de portail, d'analyse et de gestion du consentement de la plateforme.
🎧 Écouter ce guide
Voir la transcription
Résumé exécutif
La page de connexion WiFi invité — communément appelée Captive Portal ou page d'accueil — est souvent la première interaction numérique de marque qu'un visiteur a avec votre organisation. Malgré cela, la majorité des déploiements d'entreprise s'appuient sur des écrans d'accueil génériques fournis par les fournisseurs qui n'ont aucune identité de marque et ne capturent aucune donnée utile. Ce guide comble directement cette lacune.
Une expérience de connexion Guest WiFi entièrement personnalisée n'est pas une amélioration cosmétique. C'est à la fois un atout d'acquisition de données, un signal de confiance et un instrument de conformité. Lorsqu'elle est déployée correctement, elle peut augmenter les taux de capture d'e-mails de quelques pour cent à 30-40 % des invités se connectant, alimenter les données de première partie directement dans votre CRM et fournir un enregistrement de consentement GDPR vérifiable pour chaque session utilisateur. Pour les organisations opérant dans les environnements de l' hôtellerie , du commerce de détail , des soins de santé ou des transports , le cas commercial est simple.
Ce guide couvre l'architecture technique sous-jacente aux Captive Portals, la couche de personnalisation HTML/CSS, le processus de mise en œuvre en cinq étapes, les exigences de conformité au titre du GDPR et deux études de cas détaillées avec des résultats mesurables. La plateforme WiFi Analytics de Purple est référencée tout au long comme exemple concret de mise en œuvre.
Approfondissement technique
Comment fonctionne un Captive Portal
Un Captive Portal fonctionne au niveau de la couche réseau, interceptant la requête HTTP initiale d'un appareil invité et la redirigeant vers une page de connexion avant d'accorder un accès complet à Internet. Le mécanisme est standardisé chez tous les principaux fournisseurs de réseaux locaux sans fil et fonctionne indépendamment de la norme de chiffrement utilisée — ce qui signifie qu'il est entièrement compatible avec les déploiements WPA3 utilisant l'Authentification Simultanée des Égaux (SAE).
Les composants essentiels d'une architecture de Captive Portal moderne sont illustrés ci-dessous.
Le flux est le suivant. Lorsqu'un appareil invité s'associe au point d'accès et tente de charger une URL HTTP, le contrôleur de réseau local sans fil ou l'appliance de passerelle intercepte la requête et émet une redirection 302 vers le contrôleur du Captive Portal. Le contrôleur sert la page de connexion HTML/CSS personnalisée. Une fois que l'utilisateur a terminé le flux d'authentification — que ce soit via un formulaire d'e-mail, une connexion sociale (OAuth 2.0 via Facebook, Google ou Apple) ou une méthode transparente telle qu'OpenRoaming — le contrôleur communique avec un serveur RADIUS en utilisant IEEE 802.1X ou MAC Authentication Bypass (MAB) pour accorder à l'appareil l'accès au VLAN Internet. Les données capturées lors de l'authentification sont simultanément acheminées vers la plateforme de données invités ou le CRM via un appel API sécurisé, l'enregistrement de consentement GDPR étant écrit dans un magasin de données conforme.
Il est important de noter que la page du Captive Portal elle-même se charge dans un environnement de navigateur restreint — le Captive Network Assistant (CNA) sur iOS et Android — avant que l'appareil n'ait un accès complet à Internet. Cela a une implication critique pour le développement front-end : tous les actifs doivent être auto-hébergés sur le contrôleur de portail. Les ressources CDN externes, les Google Fonts et les bibliothèques JavaScript tierces ne se chargeront pas dans cet environnement. Chaque feuille de style, fichier de police et image doit être regroupé avec la page du portail et servi à partir du propre serveur web du contrôleur.
La couche de personnalisation HTML/CSS
La page de connexion elle-même est un document HTML5 standard avec une feuille de style CSS associée. Les plateformes de Captive Portal modernes — y compris Purple — exposent un éditeur visuel qui génère ce code, mais comprendre la structure sous-jacente est essentiel pour les équipes informatiques qui doivent appliquer les normes de marque ou résoudre les problèmes de rendu.
Les variables CSS clés à contrôler sont :
| Propriété CSS | Élément de marque | Approche recommandée |
|---|---|---|
background-color |
Arrière-plan de la page | Utiliser une valeur hexadécimale plate ou un dégradé CSS ; éviter les images raster |
font-family |
Typographie | Intégrer les fichiers de police WOFF2 localement ; ne pas référencer Google Fonts |
color (titres) |
Couleur secondaire de la marque | Correspondre exactement aux directives de la marque |
background-color (bouton CTA) |
Couleur principale de la marque | Utiliser la valeur hexadécimale exacte des directives de la marque |
border-radius |
Forme du bouton et du conteneur | 12px pour les conteneurs, 6px pour les petits éléments |
max-width (conteneur de formulaire) |
Disposition mobile-first | 480px maximum pour un rendu mobile optimal |
La contrainte de poids de la page est l'exigence technique la plus fréquemment violée dans les déploiements de Captive Portal. La limite pratique est de 500 kilo-octets au total pour l'ensemble de la page, y compris tous les actifs. Cela garantit un rendu fiable sur des connexions lentes ou encombrées avant l'authentification. Utilisez le format SVG pour les logos (généralement 5 à 20 Ko), les polices WOFF2 intégrées localement (généralement 30 à 80 Ko par poids) et les dégradés CSS ou les couleurs plates plutôt que les arrière-plans photographiques.
Méthodes d'authentification
Le choix de la méthode d'authentification a un impact direct sur les taux de capture de données et la posture de conformité.
| Méthode | Données capturées | Taux de conversion | Notes de conformité |
|---|---|---|---|
| Formulaire e-mail | E-mail, nom, champs personnalisés | Moyen (25–40%) | Contrôle GDPR complet ; recommandé |
| Connexion sociale (OAuth) | E-mail, nom, données de profil | Élevé (35–55%) | Nécessite un DPA avec le fournisseur social |
| SMS / OTP | Numéro de mobile | Moyen (20–35%) | Nécessite une passerelle SMS ; le PECR s'applique |
| Clic direct (pas de données) | Aucune | Très élevé (70–90%) | Pas de donune valeur ; à utiliser uniquement si nécessaire |
| OpenRoaming / Passpoint | Identité vérifiée par l'opérateur | Transparente | Écosystème Eduroam/WBA ; utilisation en entreprise |
Pour la plupart des déploiements commerciaux, une combinaison de formulaire d'e-mail et de connexion sociale — avec une case à cocher de consentement GDPR clairement présentée — offre l'équilibre optimal entre taux de conversion et qualité des données.
Guide d'implémentation
Un déploiement réussi de Captive Portal suit cinq étapes distinctes. Sauter ou compresser une étape est la cause principale des problèmes post-déploiement.
Étape 1 — Collecte des exigences. Réunir un groupe de travail interfonctionnel comprenant le marketing (actifs de marque, contenu, langage de consentement), le service juridique (examen GDPR, politique de confidentialité) et l'ingénierie réseau (architecture VLAN, configuration RADIUS, liste blanche DNS). Définir les champs de données exacts à capturer, l'URL de redirection post-authentification et le langage d'opt-in pour le consentement marketing. Obtenir l'approbation écrite du service juridique sur le mécanisme de consentement avant le début du développement.
Étape 2 — Conception et développement. Construire la page du portail comme un document HTML/CSS autonome. Appliquer la limite de poids de page de 500 Ko. Tester le rendu sur iOS Safari (CNA), Android Chrome (CNA) et les navigateurs de bureau. Valider la chaîne de certificats SSL — le domaine du portail doit avoir un certificat de confiance, car un avertissement de certificat non fiable entraînera l'abandon de la connexion par la majorité des utilisateurs. S'assurer que le formulaire est entièrement accessible (WCAG 2.1 AA minimum).
Étape 3 — Intégration. Connecter le portail à votre plateforme de données invités ou CRM via l'API de la plateforme. Configurer le serveur RADIUS (ou utiliser le service RADIUS hébergé de la plateforme). Configurer la redirection post-authentification. Configurer la segmentation VLAN pour isoler le segment réseau de pré-authentification des ressources internes. Tester le flux complet de bout en bout — association de l'appareil, redirection du portail, authentification, autorisation RADIUS, écriture des données CRM et redirection post-authentification — sur un réseau de staging avant de passer en production.
Étape 4 — Déploiement pilote. Déployer sur un seul site ou un groupe pilote défini. Surveiller quatre métriques clés pendant les 30 premiers jours : taux de réussite de l'authentification (cible >95%), temps de chargement moyen de la page (cible <3 secondes), taux de capture de données (mesure de référence) et échecs d'autorisation RADIUS (cible <1%). Résoudre tout problème avant de procéder au déploiement complet.
Étape 5 — Optimisation et gouvernance. Examiner les taux de capture de données mensuellement. Tester les variantes de titres et de textes de boutons CTA. Mettre à jour la conception du portail lorsque les directives de marque changent. Examiner le langage de consentement GDPR chaque fois que les activités de traitement des données changent. Effectuer un examen de sécurité annuel de l'infrastructure du portail, y compris le renouvellement du certificat SSL, la mise à jour du serveur RADIUS et l'examen de la liste blanche DNS.
Bonnes pratiques
Fidélité à la marque
Le portail doit passer un contrôle de fidélité à la marque en cinq points avant le déploiement : variante de logo correcte à la taille minimale (30px numérique) ; couleur du bouton principal correspondant à la valeur hexadécimale exacte de la marque ; famille de polices cohérente avec les directives de marque numériques ; ton du titre cohérent avec la voix de la marque ; et cohérence visuelle avec le site web et l'application de la marque. Tout portail qui échoue à ce contrôle doit être renvoyé à l'étape de conception.
Architecture de conformité GDPR
En vertu du UK GDPR et de l'EU GDPR, le mécanisme de consentement doit être explicite, dégroupé et granulaire. L'acceptation des conditions de service et l'opt-in pour les communications marketing doivent être présentés comme des cases à cocher séparées et non pré-cochées. Les regrouper en une seule case à cocher est non conforme. Chaque événement de consentement doit être enregistré avec un horodatage, le texte de consentement exact présenté et l'identifiant de l'utilisateur. La plateforme de Purple stocke ces enregistrements dans un registre de consentement vérifiable qui peut être exporté pour examen réglementaire.
Posture de sécurité
Le segment réseau de pré-authentification doit être isolé de toutes les ressources internes via la segmentation VLAN. Seules les entrées de la liste blanche DNS requises pour le fonctionnement du portail — le domaine du contrôleur de portail, les points de terminaison OAuth de connexion sociale et tous les domaines CDN utilisés pour les actifs auto-hébergés — doivent être accessibles avant l'authentification. Après l'authentification, les invités doivent être placés sur un VLAN invité dédié avec un accès Internet uniquement, sans aucune route vers les sous-réseaux internes. Cette architecture est conforme à l'exigence PCI DSS 1.3 pour la segmentation réseau.
Pour une comparaison détaillée des types de pages de portail, voir WiFi Landing Page vs. Splash Page : Quelle est la différence ? .
Études de cas réelles
Étude de cas 1 : Chaîne hôtelière britannique — Hôtellerie
Un groupe hôtelier de taille moyenne exploitant 45 établissements à travers le Royaume-Uni utilisait la Splash Page par défaut fournie par son fournisseur de réseau local sans fil. La page n'était pas personnalisée, se chargeait lentement sur mobile et ne présentait aucun formulaire de capture de données. Taux de capture d'e-mails : environ 8 % des invités se connectant.
L'équipe informatique a déployé la plateforme Guest WiFi de Purple dans les 45 établissements, remplaçant la Splash Page du fournisseur par un Captive Portal entièrement personnalisé. Le nouveau portail utilisait les couleurs exactes de la marque du groupe hôtelier, la typographie Poppins et une mise en page à écran unique avec un champ d'e-mail, un champ de prénom et une case à cocher de consentement marketing conforme au GDPR. Le poids total de la page a été optimisé à 380 Ko. La redirection post-authentification a été configurée vers la page d'accueil du programme de fidélité de l'hôtel.
Résultats à 90 jours : le taux de capture d'e-mails est passé de 8 % à 38 % des invités se connectant. Les données capturées ont été intégrées au CRM du groupe hôtelier, permettant une campagne d'e-mails de réengagement ciblée auprès des anciens clients. Les revenus de réservation directe attribuables à la campagne d'e-mails ont augmenté de 14 % d'une année sur l'autre dans les propriétés pilotes. Le registre de consentement GDPR a fourni une piste d'audit complète pour les 45 sites.
Étude de cas 2 : Détaillant de mode européen — Commerce de détail
Un détaillant de mode exploitant 120 magasins sur cinq marchés européens déployait le WiFi invité dans le cadre d'un programme de transformation numérique. L'exigence était un portail de marque unique, géré de manière centralisée, avec une langue par marchélocalisation linguistique (anglais, français, allemand, espagnol, italien) et une intégration CRM unique dans Salesforce.
Le détaillant a déployé une plateforme WiFi invité gérée dans le cloud avec une configuration de portail centralisée. Les éléments de marque et le CSS étaient gérés depuis une console d'administration unique, avec des surcharges par site et par région appliquées pour la langue et le texte de consentement localisé. L'intégration Salesforce utilisait le connecteur CRM natif de la plateforme.
Résultats à six mois : un actif de données de première partie de plus de 400 000 profils d'invités ayant donné leur consentement a été constitué dans les 120 magasins. Les campagnes d'e-mail auprès de cette audience ont atteint un taux d'ouverture moyen de 28 %, contre une référence sectorielle de 12 % pour le commerce de détail. Le détaillant a attribué une augmentation de 9 % des visites répétées en magasin au cours des six mois suivant le déploiement, basée sur la modélisation d'attribution CRM. Voir la plateforme WiFi Analytics de Purple pour les capacités d'analyse et d'attribution utilisées dans ce déploiement.
Dépannage et atténuation des risques
Le portail ne s'affiche pas sur iOS. iOS utilise un Captive Network Assistant (CNA) qui affiche le portail dans une vue WebKit restreinte. Assurez-vous que le domaine du portail ne figure pas sur la liste des réseaux connus d'Apple, que le portail répond correctement à la sonde de détection de Captive Portal d'Apple (/hotspot-detect.html), et que tous les actifs sont servis via HTTP (et non HTTPS) lors de la redirection initiale — le CNA ne suit pas les redirections HTTPS lors de la première requête.
Taux d'échec d'authentification élevé. Vérifiez les journaux du serveur RADIUS pour les codes d'erreur spécifiques. Les causes courantes incluent un décalage horaire entre le serveur RADIUS et le point d'accès (synchronisation NTP requise), des certificats expirés sur le serveur RADIUS et des incompatibilités de format d'adresse MAC entre le point d'accès et le serveur RADIUS.
Faible taux de capture de données malgré un volume de connexions élevé. Examinez le nombre de champs du formulaire — chaque champ supplémentaire réduit la conversion d'environ 5 à 10 %. Examinez le temps de chargement de la page — si le portail prend plus de 3 secondes à charger, l'abandon augmente fortement. Examinez le langage de consentement — un texte de consentement trop juridique réduit les taux d'adhésion.
Demande d'audit GDPR. La plateforme de Purple exporte un enregistrement de consentement complet pour toute adresse e-mail ou plage de dates donnée, sur demande. Assurez-vous que votre politique de conservation des données est configurée correctement — en vertu du GDPR britannique, les données personnelles ne doivent pas être conservées au-delà de la période nécessaire à la finalité déclarée.
Incohérence de marque entre les sites. Centralisez la gestion de la configuration du portail. Toute personnalisation au niveau du site doit être limitée au contenu et à la langue localisés ; les couleurs de la marque, la typographie et le logo doivent être verrouillés au niveau de la configuration globale.
ROI et impact commercial
Le ROI d'un Captive Portal personnalisé est mesuré selon trois dimensions : la valeur de l'actif de données, l'attribution directe des revenus et l'efficacité opérationnelle.
Valeur de l'actif de données. Le principal résultat d'un déploiement de Captive Portal est un actif de données de première partie — une base de données de profils d'invités ayant donné leur consentement avec des adresses e-mail vérifiées. La valeur de cet actif est déterminée par le taux de capture, le taux d'adhésion et la qualité des données. Un site avec 500 connexions quotidiennes, un taux de capture de 35 % et un taux d'adhésion de 70 % construira une base de données d'environ 44 000 profils ayant donné leur consentement par an. Avec un ROI de marketing par e-mail standard de l'industrie de 42 £ pour 1 £ dépensé, la valeur commerciale de cet actif est substantielle.
Attribution directe des revenus. La plateforme WiFi Analytics de Purple fournit des rapports d'attribution au niveau CRM, reliant des campagnes d'e-mail spécifiques aux visites et transactions en magasin. Cela permet un calcul direct des revenus attribuables au programme de capture de données du Captive Portal.
Efficacité opérationnelle. Une plateforme de portail gérée de manière centralisée élimine le besoin de travail de configuration informatique par site lorsque les directives de marque changent. Une seule mise à jour CSS se propage simultanément sur tous les sites, réduisant les frais généraux opérationnels de maintien de la cohérence de la marque à grande échelle.
| Métrique | Portail non marqué typique | Portail de marque (Purple) | Amélioration |
|---|---|---|---|
| Taux de capture d'e-mail | 5–10% | 30–40% | 3–4x |
| Taux d'adhésion marketing | N/A | 60–75% of captures | — |
| Engagement post-authentification | Aucun | Page de fidélité / offre | Direct |
| Préparation à l'audit GDPR | Manuel | Exportation automatisée | Significatif |
| Cohérence de la marque | Aucun | Appliquée centralement | Complète |
Pour le contexte d'architecture réseau pertinent aux déploiements multi-sites, voir Les avantages clés du SD-WAN pour les entreprises modernes , qui explique comment le SD-WAN simplifie la couche réseau sous-jacente pour les déploiements de Captive Portal distribués.
Termes clés et définitions
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.
Études de cas
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.
Analyse de scénario
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?
💡 Astuce :Consider the technical constraints of the Captive Network Assistant environment and the page weight limit.
Afficher l'approche recommandée
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?
💡 Astuce :Consider the GDPR requirements for consent to be freely given, specific, and granular.
Afficher l'approche recommandée
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?
💡 Astuce :Consider the authentication load profile and the impact of RADIUS server capacity on the user experience.
Afficher l'approche recommandée
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.
