Custom Captive Portal: Guida a HTML e CSS

Questa guida tecnica di riferimento delinea gli standard di sviluppo, l'architettura CSS e i vincoli a livello di rete necessari per progettare e codificare una landing page personalizzata per Captive Portal. Fornisce a sviluppatori frontend e architetti di rete strategie pratiche per navigare negli ambienti Apple CNA e Android webview, garantendo esperienze WiFi per gli ospiti precise al pixel, conformi e altamente performanti.

📖 11 minuti di lettura📝 2,731 parole🔧 2 esempi pratici❓ 3 domande di esercitazione📚 8 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del podcast

Custom Captive Portal: Guida a HTML e CSS — Un briefing tecnico Purple

[INTRODUZIONE]

Benvenuti alla serie di briefing tecnici Purple. Oggi scendiamo nei dettagli di un aspetto che interessa ogni singola implementazione di guest WiFi: il captive portal. Nello specifico, parleremo di come scrivere codice HTML e CSS pulito e affidabile per una landing page personalizzata di un captive portal.

Se vi è mai capitato di connettervi al WiFi di un hotel e di trovarvi davanti a una splash page non funzionante — immagini mancanti, testo senza stile, un pulsante di accesso che non risponde al tocco — avete sperimentato cosa succede quando uno sviluppatore crea un portale senza comprendere i vincoli dell'ambiente in cui viene eseguito. Oggi faremo in modo che questo non accada a voi.

Questo briefing si rivolge a sviluppatori frontend, designer creativi e sviluppatori web che stanno creando un captive portal da zero o personalizzando un template esistente. Copriremo la struttura HTML, le regole CSS fondamentali, i vincoli del mini-browser Apple CNA che mettono in difficoltà anche gli sviluppatori più esperti e come le piattaforme come il portal builder di Purple possano eliminare del tutto la maggior parte di questa complessità.

Entriamo nel vivo.

[APPROFONDIMENTO TECNICO]

Per prima cosa, stabiliamo cosa sia effettivamente un captive portal a livello di rete. Quando un dispositivo si connette a una rete WiFi che richiede l'autenticazione, la rete intercetta il traffico HTTP e reindirizza l'utente a una landing page. Questo è il captive portal. L'utente visualizza una splash page, completa un'azione — inserendo un'e-mail, accettando i termini, effettuando l'accesso tramite social — e la rete concede quindi l'accesso completo a Internet.

L'aspetto fondamentale da capire è dove viene renderizzata questa pagina. Sui dispositivi iOS, si apre all'interno del Captive Network Assistant di Apple — il CNA — che è una webview WebKit ridotta all'essenziale. Non è Safari. Non ha cookie persistenti. Non può caricare risorse esterne. Ha un supporto JavaScript limitato. E si chiude nel momento in cui l'utente passa a un'altra app. Su macOS, il CNA viene renderizzato a una risoluzione fissa di 900 per 572 pixel. Su Android, i dispositivi moderni utilizzano le Chrome Custom Tabs, che sono notevolmente più capaci. Windows 10 apre il browser predefinito dell'utente. I dispositivi Samsung utilizzano Samsung Internet.

Questa frammentazione delle piattaforme è la principale causa di malfunzionamento dei captive portal in produzione. Gli sviluppatori testano sul proprio telefono Android, tutto sembra fantastico, e poi gli ospiti dell'hotel che utilizzano un iPhone si ritrovano con una schermata bianca e testo privo di stile. Parliamo quindi di come scrivere codice in modo difensivo.

La regola d'oro per l'HTML e il CSS di un captive portal è questa: trattare la pagina come se non avesse una connessione a Internet. Perché durante la fase di autenticazione, non ce l'ha. La rete è prigioniera (captive). Qualsiasi risorsa che la pagina tenta di caricare da un URL esterno — un Google Font, un foglio di stile ospitato su CDN, una libreria JavaScript, l'immagine di un logo — fallirà silenziosamente o causerà un indicatore di caricamento infinito.Iniziando con la struttura HTML. Il documento deve essere una pagina HTML5 pulita. Nell'head, è necessario un meta tag viewport con il contenuto impostato su width equals device-width e initial-scale equals one. Questo è imprescindibile per il rendering su dispositivi mobili. Senza di esso, iOS visualizzerà la pagina a una larghezza di 980 pixel e la ridurrà in scala, rendendo tutto microscopico.

Il CSS deve essere inline — all'interno di un blocco style nell'elemento head, o come attributi style inline sui singoli elementi. Non utilizzare un foglio di stile esterno collegato tramite un tag link. Quel foglio di stile risiede sul tuo server, che la rete del Captive Portal non può raggiungere durante l'autenticazione. La pagina verrebbe visualizzata completamente priva di stile.

Per i font, utilizza uno stack di font di sistema. Qualcosa come: font-family — apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Helvetica Neue, Arial, sans-serif. Questo indica al browser di utilizzare qualsiasi font di sistema sia disponibile. Non utilizzare Google Fonts. La chiamata di importazione fallirà e il font di fallback sarà Times New Roman, che non è l'esperienza di brand per cui il tuo cliente sta pagando.

Per le immagini — il logo, la grafica di sfondo, gli elementi decorativi — hai due opzioni. Puoi ospitarle sullo stesso server del Captive Portal, il che significa che si trovano sulla stessa rete locale e sono accessibili prima del completamento dell'autenticazione. Oppure, scelta migliore, codificarle come URI di dati Base64 direttamente nel tuo HTML o CSS. Questo elimina completamente la dipendenza esterna.

Parliamo ora del layout della pagina. Poiché oltre il novanta percento degli accessi al Captive Portal avviene su dispositivi mobili, il tuo design dovrebbe essere mobile-first. Ciò significa un layout a colonna singola, con una larghezza massima di circa 480 pixel, centrato sulla pagina. Utilizza flexbox sull'elemento body — display flex, flex-direction column, align-items centre, justify-content centre, min-height 100 viewport height. Questo centra la scheda dei contenuti verticalmente e orizzontalmente su qualsiasi dimensione dello schermo.

Il pulsante di call-to-action principale deve essere facile da toccare. Le Human Interface Guidelines di Apple specificano un target di tocco minimo di 44 per 44 pixel. In pratica, per una CTA principale, è preferibile un'altezza di circa 48 pixel, a larghezza intera all'interno del contenitore, con un border-radius di circa 8-12 pixel.

Per i campi del modulo — inserimento e-mail, inserimento nome — imposta la font-size ad almeno 16 pixel. Questo è fondamentale. Safari su iOS e la CNA ingrandiranno automaticamente qualsiasi campo di input con una font-size inferiore a 16 pixel, interrompendo il layout accuratamente progettato. Impostare la font-size a 16 pixel o superiore impedisce questo comportamento di zoom.

La sezione sul consenso legale merita una particolare attenzione. Ai sensi del GDPR, se raccogli dati personali — anche solo un indirizzo e-mail — hai bisogno di un consenso esplicito e informato. Ciò significa una casella di controllo deselezionata per impostazione predefinita, con un'etichetta visibile che indichi chiaramente a cosa l'utente sta acconsentendo. Non preselezionare la casella di controllo. La casella di controllo del consenso stessa deve essere chiaramente visibile senza dover scorrere la pagina.

Ora, un dettaglio di implementazione cruciale specifico per la CNA di iOS. Quando l'utente completa l'autenticazione, la CNA monitora se il dominio captive è diventato accessibile. Il controllo viene attivato dalla navigazione dell'intera pagina, non da chiamate AJAX JavaScript. Ciò significa che se si sviluppa una single-page app che invia il modulo tramite fetch o XMLHttpRequest e aggiorna il DOM senza un reindirizzamento completo della pagina, la CNA non rileverà mai il completamento dell'autenticazione. È necessario reindirizzare a un nuovo URL dopo l'autenticazione — un reindirizzamento HTTP completo, non una manipolazione del DOM tramite JavaScript. Questo è uno degli errori più comuni nello sviluppo di un Captive Portal.

Per quanto riguarda JavaScript, riducilo al minimo. La CNA ha un supporto JS limitato e nessun accesso a localStorage o sessionStorage. I cookie vengono distrutti alla chiusura della CNA. Qualsiasi gestione dello stato che si affida a queste API del browser fallirà. I listener di eventi in Vanilla JavaScript vanno bene. jQuery è una dipendenza esterna da 30 kilobyte che non riuscirà a caricarsi.

[RACCOMANDAZIONI DI IMPLEMENTAZIONE E TRAPPOLE COMUNI]

Ecco la checklist pratica per l'implementazione. Primo: meta tag viewport, sempre. Secondo: tutto il CSS inline, nessun foglio di stile esterno. Terzo: tutte le immagini servite dal server del Captive Portal o codificate in Base64. Quarto: stack di font di sistema, nessun web font. Quinto: dimensione minima del carattere di 16 pixel su tutti i campi di input. Sesto: target di tocco ottimizzati per il touch, minimo 44 per 44 pixel. Settimo: layout a colonna singola, larghezza massima 480 pixel. Ottavo: reindirizzamento completo della pagina all'autenticazione, non un aggiornamento dello stato tramite JavaScript. Nono: casella di controllo del consenso conforme al GDPR, deselezionata per impostazione predefinita. Decimo: test su un dispositivo iOS reale utilizzando una rete captive effettiva, non un'anteprima del browser.

Le trappole che vedo più spesso in produzione. Numero uno: Google Fonts — rimuovi l'importazione, fallirà. Numero due: librerie JavaScript esterne — Bootstrap, jQuery, qualsiasi script ospitato su CDN fallirà. Numero tre: variabili CSS dichiarate in un foglio di stile esterno — devono essere nel blocco di stile inline. Numero quattro: immagini di sfondo richiamate tramite URL — codificale in Base64. Numero cinque: invio del modulo tramite AJAX senza un reindirizzamento post-autenticazione — la CNA non rileverà il completamento dell'autenticazione.

Ora, un discorso onesto sulla scelta tra sviluppo interno o acquisto. Sviluppare un Captive Portal personalizzato da zero significa essere responsabili anche dell'infrastruttura backend — il server RADIUS, il database, il certificato SSL, la configurazione DNS, l'integrazione di rete con i tuoi access point e l'applicazione continua di patch di sicurezza. Si tratta di un impegno ingegneristico notevole.

Il builder di portali di Purple offre un'interfaccia drag-and-drop con un editor HTML e CSS personalizzato per gli sviluppatori che necessitano di un controllo pixel-perfect, gestendo al contempo tutta l'infrastruttura backend — l'autenticazione, l'acquisizione dei dati, l'analitica, gli strumenti di conformità al GDPR e le integrazioni di rete con oltre 200 fornitori di access point. Ottieni il controllo creativo senza il sovraccarico dell'infrastruttura.

[DOMANDE E RISPOSTE RAPIDE]

Posso usare CSS Grid in un Captive Portal? Sì, ma testalo specificamente su iOS CNA. Flexbox ha un supporto più ampio nelle versioni WebKit più vecchie. Posso usare loghi SVG? Sì, gli SVG inline sono completamente supportati e preferibili ai PNG codificati in Base64 per i loghi perché si adattano perfettamente ai display retina. Il CNA di macOS supporta gli stessi vincoli del CNA di iOS? In linea di massima sì, con una differenza: il CNA di macOS viene renderizzato in una finestra fissa di 900 per 572 pixel. Posso usare un framework CSS come Tailwind? Solo se generi un file CSS ripulito e autonomo e lo inserisci inline nel tuo blocco di stile. E per quanto riguarda l'HTTPS? Il tuo Captive Portal deve essere servito tramite HTTP affinché il reindirizzamento iniziale funzioni: le connessioni HTTPS non possono essere intercettate dalla rete captive.

[RIASSUNTO E PROSSIMI PASSI]

Per riassumere il briefing di oggi. Un Captive Portal personalizzato è un ambiente web limitato, non un contesto browser standard. L'Apple CNA e i webview Android impongono rigide limitazioni alle risorse esterne, ai cookie, a JavaScript e allo stato della sessione. La soluzione consiste nel creare pagine HTML autonome con CSS inline, font di sistema, immagini codificate in Base64 e reindirizzamenti a pagina intera al momento dell'autenticazione.

Per i gestori di sedi e i team IT che valutano le proprie opzioni: se il vostro requisito è un portale completamente personalizzato e con il vostro brand, con HTML e CSS personalizzati, la scelta è tra creare e mantenere l'intero stack da soli — il che rappresenta un impegno ingegneristico notevole — o utilizzare una piattaforma come Purple che fornisce la funzionalità di modifica di HTML e CSS personalizzati oltre a un'infrastruttura backend di livello di produzione.

I prossimi passi da compiere: consultare la documentazione dell'editor del portale di Purple, verificare il portale esistente rispetto alla checklist mobile-first che abbiamo esaminato oggi e, se si parte da zero, utilizzare la struttura del modello HTML che abbiamo delineato come base di partenza. Grazie per l'attenzione e ci vediamo al prossimo briefing.

Punti chiave

✓I Captive Portal vengono eseguiti in mini-browser altamente limitati (come il Websheet di Apple iOS) che bloccano fogli di stile esterni, web font, cookie e memoria locale.
✓Progettare per la "connettività zero" è obbligatorio: tutto il CSS deve essere inline e le risorse visive devono essere incorporate direttamente come Data URI Base64.
✓È richiesto un reindirizzamento HTTP a pagina intera dopo il login andato a buon fine per attivare l'handshake di uscita di iOS; gli aggiornamenti DOM basati su AJAX lasceranno i dispositivi bloccati in un loop del captive.
✓I layout mobile-first devono presentare una struttura a scheda a colonna singola (larghezza massima: 480px), target touch-friendly (minimo 44px) e font di input di almeno 16px per impedire lo zoom automatico.
✓La conformità legale ai sensi del GDPR richiede caselle di controllo esplicite e deselezionate di default per il consenso al marketing, separate dall'accordo standard sui Termini di Servizio.
✓Sebbene la codifica personalizzata offra una completa libertà creativa, l'hosting e la scalabilità dei server RADIUS, la sicurezza dei database e le integrazioni multi-vendor comportano enormi costi operativi.
✓La piattaforma di Purple combina il controllo dell'area di lavoro HTML/CSS a livello di sviluppatore con un'infrastruttura RADIUS sicura, cloud-native e distribuita a livello globale, oltre a strumenti di conformità nativi.

📚 Part of our core series: La Guida Definitiva ai Captive Portals →

Executive Summary

Per le strutture aziendali—che spaziano dagli hotel di lusso Hospitality e catene di negozi Retail agli hub di transito Transport e moderni campus medici Healthcare —la splash page del WiFi per gli ospiti rappresenta la porta d'ingresso digitale. Tuttavia, oltre il 90% degli accessi al WiFi per gli ospiti avviene su dispositivi mobili, dove la visualizzazione non è gestita da browser standard come Safari o Chrome, ma da webview altamente limitate del Captive Network Assistant (CNA) [1]. Questi "mini-browser" impongono severe limitazioni di sandbox: bloccano i CDN esterni, disabilitano i cookie persistenti, ignorano i web font esterni e limitano fortemente l'esecuzione di JavaScript per mitigare i rischi di sicurezza e prevenire il dirottamento delle sessioni [2].

Quando uno sviluppatore progetta una splash page utilizzando i tradizionali standard web, questi vincoli si traducono in layout interrotti, elementi del brand mancanti e pulsanti di login non funzionanti, con un impatto diretto sulla soddisfazione del cliente e sul coinvolgimento digitale. Questa guida fornisce soluzioni a queste sfide, presentando pratiche di codifica difensive—come CSS inline, codifica degli asset in Base64, stack di font di sistema e handshake di autenticazione espliciti basati sulla navigazione—per garantire una visualizzazione multipiattaforma fluida. Inoltre, esaminiamo come l'utilizzo di una soluzione gestita come il portal builder di Purple consenta agli sviluppatori di mantenere il controllo creativo completo su HTML/CSS, delegando al contempo l'autenticazione RADIUS, la scalabilità del database, la conformità GDPR/PCI e le integrazioni AP multi-vendor [3].

Technical Deep-Dive

Per creare un Captive Portal personalizzato e resiliente, gli sviluppatori devono comprendere l'intercettazione a livello di rete e la virtualizzazione del browser che si verificano quando un ospite si associa a un Service Set Identifier (SSID) aperto.

Il Ciclo di Vita del Captive Portal

Quando un dispositivo client si associa a un SSID captive, viene avviata la seguente sequenza:

Associazione IP: Il dispositivo completa un handshake a 3 vie e richiede un indirizzo IP tramite DHCP.
Probe di Connettività Attiva: Il gestore di rete in background del sistema operativo invia immediatamente una richiesta HTTP GET a un URL canary dedicato e neutrale rispetto al fornitore (ad es., http://captive.apple.com/hotspot-detect.html di Apple o http://connectivitycheck.gstatic.com/generate_204 di Google) [1].
Intercettazione DNS/HTTP: Il Wireless LAN Controller (WLC) o l'Access Point (AP) locale intercetta questa richiesta HTTP sulla porta 80. Invece di restituire lo stato HTTP 200 o 204 previsto, il gateway reindirizza il traffico del client all'URL della pagina di destinazione del captive portal tramite un reindirizzamento HTTP 302 [2].
Generazione della Webview: Rilevando il reindirizzamento, il sistema operativo avvia il proprio mini-browser nativo Captive Network Assistant (CNA) per visualizzare la splash page reindirizzata, evitando che l'utente debba aprire manualmente un browser completo.
Autenticazione e transizione di stato: l'utente compila il modulo di login, inviando le credenziali al server del portale, che istruisce il gateway (spesso tramite un Access-Accept RADIUS o una chiamata API esterna) ad autorizzare l'indirizzo MAC.
Handshake di uscita del CNA: il mini-browser del CNA esegue un altro HTTP GET verso il suo URL canary. Se riceve la risposta 200/204 prevista, cambia il pulsante in alto a destra da "Annulla" a "Fine" e stabilisce la connessione WiFi come interfaccia di rete primaria.

Vincoli del mini-browser specifici per piattaforma

Ogni sistema operativo gestisce questo ciclo di vita all'interno di diversi ambienti webview, con un conseguente comportamento altamente frammentato. La tabella seguente dettaglia questi vincoli critici:

Piattaforma / Webview	Metodo di visualizzazione	Cookie persistenti	Web Font esterni	Esecuzione JavaScript	Dimensioni della finestra	Trigger dell'handshake di uscita
Apple iOS CNA (Websheet)	Popup del mini-browser	Bloccati (Distrutti alla chiusura)	Bloccati (Offline)	Limitata (No localStorage/sessionStorage)	Responsive (Larghezza dispositivo)	Solo reindirizzamento HTTP a pagina intera [1]
Apple macOS CNA (Captive Network Assistant)	Popup del mini-browser	Bloccati	Bloccati	Limitata (No finestre di dialogo alert/confirm)	Fisse (900px x 572px)	Solo reindirizzamento HTTP a pagina intera
Android (Google) (CaptivePortalLogin)	Notifica push -> Scheda personalizzata Chrome	Consentiti (Condivisi con Chrome)	Consentiti (Se inseriti nella whitelist del walled garden)	Completa	Responsive	Automatico (Captive Portal API / Verifica 204) [2]
Samsung Android (Samsung Internet)	Notifica push -> Mini-browser	Consentiti	Consentiti	Completa	Responsive	Automatico
Windows 10/11 (Browser predefinito)	Avvio automatico del browser predefinito	Consentiti (Contesto browser completo)	Consentiti	Completa	Responsive	Manuale / Automatico

Sviluppare codice per aggirare la trappola del pulsante "Fine" del CNA Apple

Uno dei problemi di malfunzionamento più frequenti nello sviluppo di portali personalizzati è la trappola del pulsante "Fine" sui dispositivi iOS. Quando un utente si autentica, la webview Websheet di iOS deve rilevare che la rete non è più captive. Per farlo, monitora il successo delle sue richieste canary in background.

Fondamentalmente, il CNA di iOS attiverà questo controllo solo a seguito di una navigazione HTTP a pagina intera (reindirizzamento di posizione). Se uno sviluppatore crea una moderna Single Page Application (SPA) che invia i dati del modulo tramite una chiamata AJAX asincrona (ad es. fetch() o Axios) e aggiorna il DOM in modo dinamico senza modificare l'URL, il CNA non eseguirà mai nuovamente il controllo di connettività. L'utente verrà autenticato a livello di gateway, ma il pulsante del CNA nell'angolo in alto a destra rimarrà impostato su "Annulla". Se l'utente frustrato fa clic su "Annulla", il dispositivo iOS si disassocierà immediatamente dall'SSID, interrompendo la sessione WiFi [1].

Per evitare questo problema, il gestore del successo dell'autenticazione deve eseguire un reindirizzamento a pagina intera verso una landing page fisica (ad es. window.location.href = '/success') o inviare il modulo di login in modo nativo tramite un'azione HTTP POST standard.

Guida all'implementazione

Per garantire un rendering coerente su tutte le piattaforme, gli sviluppatori devono passare da un web design moderno e ricco di risorse a uno stile di codifica altamente autonomo e difensivo.

La regola d'oro: progettare per l'assenza di connettività Internet

Durante lo stato captive, il dispositivo client non ha alcun accesso a Internet. Può solo risolvere e accedere a indirizzi IP e domini esplicitamente inseriti nella whitelist del Walled Garden del controller wireless (come l'IP del server del Captive Portal stesso). Pertanto, qualsiasi risorsa esterna a cui si fa riferimento nell'HTML non riuscirà a caricarsi, compromettendo il layout.

Per progettare in modo difensivo, implementa la seguente Checklist per la progettazione di Captive Portal Mobile-First:

1. Configurazione del Viewport

Per evitare che i dispositivi mobili riducano il viewport a una larghezza desktop (in genere 980px), l'elemento HTML `` deve includere un meta tag viewport reattivo. Senza di questo, il testo e i campi di input appariranno microscopici sui dispositivi mobili:

2. Incorporare il CSS e rimuovere le dipendenze esterne

Non collegare mai file CSS esterni o CDN (ad es. Bootstrap, Tailwind o Google Fonts). Tutto il CSS deve essere incorporato all'interno di un blocco `

<div class="portal-card">
    <div class="logo-container">
        
        
            
            IL TUO BRAND
        
    </div>
    
    <h1>Benvenuto nel WiFi Ospiti</h1>
    <p>Inserisci i tuoi dati qui sotto per accedere a Internet in modo sicuro e ad alta velocità.</p>
    
    
    
        <div class="form-group">
            Nome e Cognome
            
        </div>
        
        <div class="form-group">
            Indirizzo Email
            
        </div>
        
        <div class="consent-group">
            
            
                Accetto i <a href="#">Termini di Servizio</a> e acconsento al trattamento dei dati in conformità con le normative GDPR.
            
        </div>
        
        <div id="terms_box" class="terms-scrollbox">
            <strong>Termini di Servizio WiFi:</strong><br />
            1. Questo servizio viene fornito così com'è, senza garanzie.<br />
            2. Gli utenti non devono svolgere attività illegali ad alta intensità di banda.<br />
            3. I dati personali vengono raccolti esclusivamente per l'autenticazione e l'adesione al marketing in conformità con la nostra Informativa sulla Privacy.
        </div>
        
        Connettiti al WiFi
    
    
    <div class="footer">
        Powered by Purple | Secure Guest WiFi
    </div>
</div>


## Risoluzione dei problemi e mitigazione dei rischi

Durante l'implementazione di Captive Portal con codice HTML/CSS personalizzato, i team operativi IT si scontrano frequentemente con diversi gravi rischi operativi:

### 1. Il loop di avviso del certificato SSL/TLS

Poiché i Captive Portal funzionano intercettando il traffico, presentano un conflitto fondamentale con la moderna sicurezza web HTTPS. Quando un utente tenta di visitare un sito HTTPS (ad es. `https://www.google.com`) e il gateway tenta di reindirizzare quel traffico a un Captive Portal HTTP, il browser rileva una discrepanza nel certificato SSL e mostra un avviso di sicurezza critico "La tua connessione non è privata". 

* **Mitigazione**: Non tentare mai di intercettare direttamente il traffico HTTPS. Affidarsi interamente all'assistente CNA nativo del sistema operativo (che effettua una richiesta HTTP non crittografata per attivare il reindirizzamento). Assicurarsi che il dominio del Captive Portal disponga di un certificato SSL valido e pubblicamente attendibile (ad es. Let's Encrypt o DigiCert) e che sia servito tramite HTTPS *solo dopo* che il reindirizzamento HTTP iniziale ha indirizzato con successo l'utente al dominio del portale [2].

### 2. Errori di risoluzione DNS (La trappola del Walled Garden)

Se la tua pagina HTML personalizzata fa riferimento a risorse esterne, come un endpoint OAuth per il login social (ad es. Facebook, Google) o un gateway di pagamento, le richieste DNS per questi domini falliranno a meno che non siano esplicitamente inserite nella whitelist del Walled Garden del controller wireless. Se un dominio manca dalla whitelist, il flusso di login si bloccherà, mostrando una schermata vuota.

* **Mitigazione**: Mantieni un elenco di Walled Garden rigoroso e minimale. Se utilizzi i login social, inserisci nella whitelist i domini wildcard specifici consigliati dagli identity provider (ad es. `*.google.com`, `*.gstatic.com`). 

### 3. Vulnerabilità di Session Timeout e MAC Spoofing

I Captive Portal standard autenticano i dispositivi in base ai loro indirizzi MAC. Tuttavia, i moderni sistemi operativi mobili (iOS 14+ e Android 10+) utilizzano per impostazione predefinita indirizzi MAC casuali (indirizzi WiFi privati), ruotandoli periodicamente. Ciò può far sì che agli ospiti venga richiesto ripetutamente di autenticarsi di nuovo, compromettendo l'esperienza utente [1].

* **Mitigazione**: Implementa timeout di sessione ragionevoli (ad es. 24 ore) sul server RADIUS per prevenire sessioni obsolete e utilizza standard di autenticazione moderni come **Passpoint (Hotspot 2.0)** o **WPA3-Enterprise** per un onboarding sicuro e fluido che bypassi completamente i Captive Portal basati su MAC.

## Rilevanza del Prodotto Purple: Sviluppo Interno vs. Acquisto

Sebbene la codifica di una singola pagina HTML sia semplice, l'hosting, la sicurezza e la scalabilità di un'infrastruttura di Captive Portal personalizzata presentano enormi ostacoli tecnici e di conformità. La tabella seguente confronta le realtà ingegneristiche e operative dell'hosting autonomo di un portale personalizzato rispetto all'utilizzo della piattaforma aziendale gestita di Purple:

| Funzionalità / Requisito Operativo | Portale Personalizzato in Self-Hosting | Piattaforma Purple Enterprise WiFi |
| :--- | :--- | :--- |
| **Personalizzazione HTML/CSS** | Codifica completamente manual, caricamento dei file sui singoli AP o server web locali. | **Editor per sviluppatori pixel-perfect** che consente l'inserimento di HTML/CSS personalizzati, combinato con un builder visivo drag-and-drop.
| **Infrastruttura RADIUS** | È necessario distribuire, configurare e mantenere server FreeRADIUS o Cloud RADIUS ad alta disponibilità [4]. | **RADIUS nativo del cloud, distribuito a livello globale e integrato** con ridondanza active-active e SLA di uptime del 99,99%.
| **Supporto AP Multi-Vendor** | Script di integrazione personalizzati richiesti per ciascun fornitore di hardware (Cisco, Aruba, Meraki, Ruckus) [5]. | **Integrazione nativa e immediata** con oltre 200 modelli di hardware; implementazione unificata del portale su parchi macchine con hardware misto.
| **Privacy dei Dati e Conformità** | La sede si assume il 100% della responsabilità legale per la conformità a GDPR, CCPA e PCI DSS, inclusi la crittografia sicura del database e i flussi di lavoro per la cancellazione dei dati. | **Completamente conforme fin dalla progettazione**. Gestione del consenso integrata, richieste automatizzate di cancellazione dei dati degli interessati e hosting sicuro certificato ISO 27001.
| **Analytics &amp; Marketing** | Richiede la creazione di pipeline personalizzate per l'acquisizione dei dati e l'integrazione di strumenti di marketing di terze parti. | **Dashboard di analytics di livello enterprise** con tracciamento delle presenze in tempo reale, metriche sul tasso di ritorno e trigger automatici per campagne di marketing [6].
| **Integrazioni con Identity Provider** | Integrazioni manuali OAuth2 con Google, Facebook, Apple e gateway SMS locali. | **Integrazioni con un solo clic** con le principali piattaforme social, gateway SMS e Azure AD / Okta per gli ospiti aziendali.

La piattaforma di Purple risolve il dilemma "Build vs. Buy". Offre agli sviluppatori la completa libertà creativa di uno spazio di lavoro HTML/CSS personalizzato, eliminando al contempo la complessa e rischiosa ingegnerizzazione dell'infrastruttura backend necessaria per supportare l'autenticazione RADIUS sicura su scala.

## ROI e Impatto Aziendale

Investire in un Captive Portal personalizzato, reattivo e progettato in modo professionale offre ritorni quantificabili in termini di operazioni IT, marketing e conformità legale.

### 1. Riduzione dei Costi Operativi (Ticket dell'Helpdesk IT)

Nelle implementazioni su larga scala, come uno stadio o una catena di vendita al dettaglio multi-sito, un Captive Portal non funzionante è una delle cause principali dell'aumento dei ticket di assistenza IT. Quando gli ospiti visualizzano una "schermata bianca" o un pulsante di accesso che non risponde, sovraccaricano il personale in loco o inviano ticket di supporto.

$$\text{Risparmio Annuale sul Supporto} = (\text{Visite Annuali Totali degli Ospiti} \times \text{Tasso di Errore del Portale} \times \text{Tasso di Contatto Helpdesk}) \times \text{Costo per Singolo Ticket}$$

* **Scenario**: Un centro congressi con 1.000.000 di visitatori annuali. Un portale codificato male ha un tasso di errore del 5% sui dispositivi iOS più vecchi, con un conseguente tasso di contatto dell'helpdesk del 10%. Con un costo standard del settore di $15 per ticket di supporto, il costo operativo è:
  $$(1,000,000 \times 0.05 \times 0.10) \times \$15 = \$75,000 \text{ all'anno in costi di supporto evitabili}$$
* **Risultato**: Il passaggio a un modello ottimizzato per CNA e mobile-first riduce il tasso di errore del portale a &lt;0,1%, eliminando virtualmente questo spreco operativo.

### 2. Acquisizione dei Dati di Marketing e Ottimizzazione dell'Opt-in

Per i punti vendita al dettaglio e le strutture ricettive, il Captive Portal per il WiFi degli ospiti è il meccanismo principale per acquisire dati di prima parte puliti sui clienti. Un'interfaccia utente progettata male, con testi microscopici o un layout del modulo macchinoso, causa elevati **tassi di rimbalzo** (bounce rate): gli utenti abbandonano completamente il processo di accesso, con conseguente perdita di opportunità di marketing.

* **Caso di Studio (Retail)**: Una catena di vendita al dettaglio nazionale ha implementato un Captive Portal ottimizzato per dispositivi mobili utilizzando la piattaforma di Purple. Sostituendo un modulo di accesso a più passaggi con un campo di inserimento email singolo (dimensione carattere: 16px) e un pulsante ottimizzato con area di tocco di 48px, ha registrato un **aumento del 42% delle registrazioni completate** e un **aumento del 28% delle iscrizioni alla newsletter di marketing** nel primo trimestre [6].

### 3. Mitigazione dei Rischi Legali e Normativi

In base al GDPR e al CCPA, la raccolta di dati non conforme comporta severe sanzioni finanziarie (fino al 4% del fatturato annuo globale ai sensi del GDPR). Affidarsi a caselle di controllo preselezionate o non fornire un'Informativa sulla Privacy chiara e facilmente accessibile sulla splash page espone l'azienda a enormi responsabilità legali.

* **ROI della mitigazione**: L'implementazione di una casella di consenso esplicita e non selezionata e l'hosting dei termini all'interno di una casella di scorrimento ottimizzata garantiscono la conformità normativa al 100%, mitigando il rischio di sanzioni regolatorie multimilionarie e proteggendo la reputazione del marchio.

## Riepilogo dei punti chiave

* **La sandbox CNA è restrittiva**: Il Websheet iOS di Apple e il CNA di macOS sono ambienti altamente isolati (sandboxed) che bloccano risorse esterne, cookie e font web. Tutti gli stili e le risorse devono essere autonomi (CSS inline, immagini Base64, font di sistema) [1].
* **AJAX interrompe l'handshake di uscita di iOS**: Per far passare con successo il dispositivo iOS da "captive" a "connesso" (cambiando il pulsante in alto a destra da "Annulla" a "Fine"), è necessario attivare un reindirizzamento HTTP a pagina intera. Gli aggiornamenti asincroni del DOM lasceranno il dispositivo in un loop captive.
* **L'approccio Mobile-First è obbligatorio**: Oltre il 90% degli accessi avviene su dispositivi mobili. Progetta un layout a colonna singola (larghezza massima: 480px), utilizza target di tocco ottimizzati per il mobile (minimo 44px x 44px) e imponi una dimensione minima del carattere di 16px su tutti i campi di testo per impedire lo zoom automatico del browser iOS.
* **I Walled Garden controllano il DNS**: Qualsiasi dominio esterno a cui si fa riferimento durante l'accesso (ad esempio, le API di social login) deve essere esplicitamente inserito nella whitelist del walled garden del controller wireless, altrimenti la pagina non verrà caricata.
* **Purple elimina la complessità del backend**: L'utilizzo del costruttore di portali di Purple offre agli sviluppatori il controllo completo di HTML/CSS tramite un editor personalizzato, eliminando al contempo gli enormi oneri di sicurezza, scalabilità e conformità di RADIUS, delle integrazioni AP multi-vendor e della gestione dei database conforme al GDPR [3].

## Riferimenti

* [1] [Wireless Broadband Alliance: Captive Network Portal Behavior](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] [Come implementare l'autenticazione 802.1X con Cloud RADIUS](/guides/implementing-8021x-with-cloud-radius)
* [5] [Cisco Wireless APs: Guida 2026 ai prodotti e all'implementazione](/blog/cisco-wireless-ap)
* [6] [Piattaforma di Marketing e Analytics Purple WiFi](/guest-wifi-marketing-analytics-platform)

---

## Ascolta il briefing tecnico

Ascolta un senior solutions architect discutere i vincoli tecnici e le strategie di implementazione per i Captive Portal personalizzati:

Definizioni chiave

Captive Portal

Una pagina web visualizzata agli utenti appena connessi a una rete Wi-Fi prima che venga concesso loro un accesso più ampio alle risorse di rete, tipicamente utilizzata per l'autenticazione, il pagamento o la visualizzazione dei termini di servizio.

I team IT distribuiscono i captive portal a livello di gateway per controllare l'accesso degli ospiti, acquisire i dati degli utenti e garantire la conformità legale.

Captive Network Assistant (CNA)

Un mini-browser sandboxed e altamente limitato, avviato automaticamente dai sistemi operativi (come Apple iOS e macOS) al rilevamento di un reindirizzamento di rete captive, progettato esclusivamente per facilitare l'autenticazione al portale.

Le webview del CNA impongono limitazioni severe, tra cui il blocco di CDN esterne, cookie persistenti e storage locale, che spesso compromettono i layout web standard.

Walled Garden

Un elenco limitato di indirizzi IP, subnet o nomi di dominio a cui un utente ospite non autenticato è autorizzato ad accedere tramite il gateway prima di completare il processo di accesso al Captive Portal.

Gli sviluppatori devono assicurarsi che qualsiasi risorsa esterna (come le API di login social o i gateway di pagamento) sia inserita nella whitelist del walled garden per evitare che il flusso di login si blocchi.

Base64 Encoding

Uno schema di codifica da binario a testo che rappresenta i dati binari (come le immagini) come una stringa ASCII, consentendo di incorporare le risorse direttamente all'interno di documenti HTML o CSS.

L'utilizzo della codifica Base64 per loghi e icone elimina le richieste HTTP esterne, garantendo che gli elementi grafici vengano visualizzati perfettamente all'interno di ambienti CNA offline.

RADIUS (Remote Authentication Dial-In User Service)

Un protocollo di rete che fornisce una gestione centralizzata di autenticazione, autorizzazione e contabilità (AAA) per gli utenti che si connettono e utilizzano un servizio di rete.

Il server del Captive Portal comunica con un server RADIUS per autorizzare l'indirizzo MAC dell'ospite sul gateway di rete una volta soddisfatti i criteri di autenticazione.

System Font Stack

Una dichiarazione CSS font-family che dà la priorità ai font preinstallati nel sistema operativo (come San Francisco su iOS, Segoe UI su Windows e Roboto su Android) rispetto ai web font esterni.

L'implementazione di un system font stack garantisce il rendering immediato dei caratteri senza attivare richieste HTTP esterne bloccate verso servizi come Google Fonts.

Canary URL

Un URL HTTP dedicato e non crittografato gestito dai fornitori di sistemi operativi (ad es. captive.apple.com) per verificare se un dispositivo dispone di una connettività Internet illimitata.

Il gestore di rete in background del sistema operativo controlla questo URL per rilevare la presenza di un Captive Portal e attivare il popup della webview del CNA.

Passpoint (Hotspot 2.0)

Uno standard di settore sviluppato dalla Wi-Fi Alliance che consente ai dispositivi mobili di rilevare automaticamente e autenticarsi in modo sicuro con gli hotspot Wi-Fi, aggirando i login manuali del Captive Portal.

Le aziende utilizzano Passpoint insieme a piattaforme come Purple per far passare gli ospiti da splash page complesse a esperienze di roaming sicuro e fluido, simili a quelle della rete cellulare.

Esempi pratici

Una catena di hotel di lusso da 250 camere [Hospitality](/industries/hospitality) desidera implementare una pagina di login WiFi personalizzata per gli ospiti che si adatti perfettamente alle linee guida del proprio brand premium. La loro agenzia creativa ha progettato una splash page che utilizza una tipografia di brand personalizzata (ospitata su Adobe Fonts), molteplici immagini di sfondo ad alta risoluzione (ospitate su un bucket AWS S3 pubblico) e un wizard JavaScript animato multi-step. Una volta implementato, gli ospiti con dispositivi iOS si connettono all'SSID, ma il portale appare come una schermata bianca vuota e gli utenti non riescono ad autenticarsi.

Per risolvere il problema della schermata vuota e del branding non funzionante, dobbiamo ristrutturare l'architettura frontend del portale per conformarci ai vincoli della sandbox del CNA di Apple:

Risoluzione della tipografia: Poiché Adobe Fonts richiede una richiesta HTTP esterna che viene bloccata dal CNA, sostituiamo la chiamata al font personalizzato con uno stack di font di sistema nativo e premium (font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Helvetica, Arial, sans-serif;). Ciò garantisce un rendering istantaneo senza chiamate di rete esterne.
Ottimizzazione degli asset: Le immagini di sfondo su AWS S3 sono bloccate perché S3 non si trova nel walled garden del gateway. Comprimiamo il logo principale del brand, lo convertiamo in un SVG leggero e lo codifichiamo direttamente nell'HTML come Data URI Base64. Per lo sfondo, sostituiamo le immagini pesanti con un gradiente CSS pulito e reattivo che utilizza i colori del brand dell'hotel, riducendo significativamente il peso della pagina.
Semplificazione di JavaScript: Il wizard animato multi-step si basa su librerie esterne jQuery e GSAP. Eliminiamo queste dipendenze esterne e rifattorizziamo il modulo in una struttura HTML a pagina singola e a colonna singola. La validazione del modulo viene riscritta in JavaScript vanilla leggero.
Handshake di autenticazione: L'invio del modulo viene modificato da un invio basato su AJAX a un <form action="/submit" method="POST"> HTML nativo per attivare un reindirizzamento a pagina intera, consentendo al Websheet di iOS di eseguire il suo controllo canary e mostrare il pulsante 'Fine'.

Commento dell'esaminatore: Questo scenario rappresenta il classico conflitto tra il design creativo di alto livello e i rigidi vincoli di sicurezza delle webview captive. Le agesie creative spesso trattano il Captive Portal come un normale sito web desktop. Tuttavia, poiché il dispositivo si trova in uno stato di pre-autenticazione, la rete blocca tutto il traffico esterno. Incorporando il CSS, utilizzando font di sistema, codificando gli asset in Base64 e utilizzando invii di moduli nativi, preserviamo l'estetica del brand premium garantendo al contempo l'affidabilità operativa al 100% sui dispositivi iOS e Android.

Una catena di vendita al dettaglio nazionale [Retail](/industries/retail) con 450 negozi desidera acquisire le e-mail degli ospiti tramite le splash page WiFi per alimentare il proprio CRM. Richiedono agli ospiti di prestare il consenso alla ricezione di newsletter di marketing. Il design iniziale presenta una casella di controllo preselezionata "Accetto di ricevere e-mail di marketing". Inoltre, il portale è ospitato su un unico server locale nella loro sede centrale. Durante le ore di punta (sabato pomeriggio), gli ospiti in tutto il paese riscontrano gravi ritardi e molti non riescono a caricare la pagina di login, causando un drastico calo dei tassi di acquisizione dei dati.

Dobbiamo affrontare sia la violazione della conformità sia il collo di bottiglia dell'infrastruttura:

Risoluzione della conformità: Ai sensi del GDPR e del CCPA, le caselle di consenso preselezionate sono illegali. Modifichiamo l'HTML per fare in modo che la casella di controllo del consenso al marketing non sia selezionata per impostazione predefinita (<input type="checkbox" id="marketing_consent">). Aggiungiamo anche una casella di controllo separata e obbligatoria per i Termini di servizio per separare l'accordo legale dal consenso al marketing.
Scalabilità dell'infrastruttura: Ospitare un Captive Portal nazionale su un singolo server centralizzato crea un singolo punto di guasto e un enorme collo di bottiglia per la latenza. Migriamo il frontend del portale su una Content Delivery Network (CDN) altamente disponibile e distribuita a livello globale con edge-caching.
Integrazione RADIUS: Configuriamo gli access point dei negozi locali per puntare a un cluster RADIUS cloud-native con ridondanza active-active, garantendo che le richieste di autenticazione vengano elaborate localmente all'edge con una latenza inferiore a 50 ms, anche durante il picco di traffico del sabato.
Migrazione a Purple: Per eliminare l'intero sovraccarico ingegneristico, il retailer migra a Purple. Gli strumenti di consenso GDPR integrati di Purple gestiscono automaticamente i consensi conformi e la loro infrastruttura cloud distribuita a livello globale gestisce milioni di autenticazioni giornaliere con un uptime del 99,99%, risolvendo completamente il collo di bottiglia della scalabilità.

Commento dell'esaminatore: Le caselle di consenso preselezionate rappresentano un grave rischio di conformità che può portare a massicce sanzioni normative. Separare il consenso al marketing dai Termini di servizio è una best practice tecnica e legale. Dal punto di vista dell'infrastruttura, l'hosting centralizzato dei Captive Portal è un anti-pattern. Una presenza retail su scala nazionale richiede un frontend decentralizzato con edge-cache combinato con un backend RADIUS cloud-native. La migrazione a una piattaforma gestita come Purple elimina questa complessità architetturale, consentendo al retailer di concentrarsi sulle campagne di marketing anziché sulla scalabilità del database.

Domande di esercitazione

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?

Suggerimento: 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.

Visualizza risposta modello

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?

Suggerimento: 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.

Visualizza risposta modello

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:

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.
Set to Unchecked: Ensure both checkboxes are unchecked by default in the HTML (checked attribute omitted).
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.
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?

Suggerimento: 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.

Visualizza risposta modello

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:

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.
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.
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.

Continua a leggere questa serie

Come configurare un Captive Portal su Starlink: una guida per sedi remote e marittime

Questa guida spiega in dettaglio come escludere l'hardware nativo di Starlink e integrare un Captive Portal gestito in cloud utilizzando apparecchiature di routing aziendali. Imparerai come superare il limite del CGNAT, applicare la segmentazione VLAN, gestire i vincoli di larghezza di banda satellitare e garantire la conformità normativa.

Captive Portal Best Practices: Progettazione per Conversioni Elevate e Compliance

Questa guida tecnica offre a IT manager, architetti di rete e direttori operativi delle location un modello completo per l'implementazione di Captive Portal in grado di bilanciare la sicurezza di rete con un tasso elevato di conversione degli utenti. Copre l'intera architettura, dalla segmentazione VLAN e autenticazione RADIUS fino alla progettazione del consenso conforme al GDPR e alla selezione del metodo di autenticazione. Basata sull'esperienza operativa di Purple in oltre 80.000 location e 440 milioni di login nel 2024, ogni raccomandazione è fondata su dati reali di implementazione.

Come ottimizzare i Captive Portal per la massima sicurezza di rete e conversione degli utenti

Questa guida fornisce un progetto tecnico completo per l'ottimizzazione dei captive portal all'interno di strutture aziendali, coprendo l'architettura di segmentazione della rete, la selezione dei metodi di autenticazione, la progettazione del consenso conforme al GDPR e l'ottimizzazione delle conversioni. È scritta per IT manager, architetti di rete e CTO di hotel, catene di vendita al dettaglio, stadi e organizzazioni del settore pubblico che devono bilanciare la sicurezza della rete con l'acquisizione di dati di prima parte. Purple gestisce l'infrastruttura dei captive portal in oltre 80.000 sedi con 440 milioni di accessi nel 2024, e i framework qui presentati riflettono tale esperienza operativa.