Accesso al portale captive Android: Come accedere e risolvere i problemi

Si trova nella hall di un hotel, lo smartphone indica Connesso e non carica alcun contenuto. Nessuna pagina di login, nessun errore su cui poter intervenire, solo le applicazioni in caricamento continuo mentre l'icona WiFi mostra un piccolo avviso. In questo caso, l'accesso al portale captive Android non sta funzionando correttamente, oppure la rete risponde ai controlli di Android in un modo che lascia lo smartphone bloccato tra connesso e online.

La soluzione consiste raramente nel premere pulsanti a caso. Android segue una precisa macchina a stati di rilevamento e, una volta individuato lo stato in cui ci si trova, si saprà cosa premere, quale impostazione modificare o se il problema dipenda dalla struttura. Consigliamo di iniziare dalla notifica di sistema, per poi passare al browser, alle impostazioni sulla privacy e infine alla struttura stessa del portale.

Sommario

• Accedere a un portale captive su Android in meno di un minuto
• In che modo Android stabilisce se una rete richiede l'accesso
  • Chi fa cosa all'interno di Android
  • Lettura della risposta della rete
• Risolvere i problemi di accesso sul proprio telefono
• Problemi noti con il rilevamento del portale captive
  • Dove si interrompe la macchina a stati
• Dispositivi Android gestiti e Kiosk
• Scegliere un layout di portale idoneo per Android

Accedere a un portale captive su Android in meno di un minuto

Tocchi la notifica Accedi alla rete prima di aprire Chrome. Android la apre nella propria schermata di accesso, tiene traccia delle scelte effettuate e ricontrolla la rete al termine. Una scheda del browser aperta manualmente non riceve alcun trattamento di questo tipo, ed è il motivo per cui chi ignora la richiesta si ritrova spesso con una pagina di accesso effettuato e uno smartphone che continua a segnalare l'assenza di Internet.

1. Toccare la notifica di accesso alla rete. Scorrere verso il basso la tendina delle notifiche o toccare l'avviso sotto il nome del WiFi WiFi. Di solito viene visualizzato pochi secondi dopo la connessione e reindirizza direttamente alla pagina della struttura senza dover inserire l'URL.
2. Se non compare alcuna notifica, aprire una semplice pagina HTTP. Nel browser, visitare un indirizzo http e non HTTPS. Il portale può intercettare e reindirizzare una richiesta semplice, mentre una pagina crittografata bloccherà la navigazione o mostrerà un avviso sul certificato. Scegliere un indirizzo che non è stato visitato di recente, in modo che il browser non risponda attingendo dalla cache ignorando completamente la rete.
3. Completare il passaggio richiesto dalla struttura. Accettare i termini, inserire il numero di stanza, digitare il codice SMS o utilizzare il login social proposto. Non chiudere la finestra in anticipo, poiché Android necessita del segnale di completamento per ripetere il test.
4. Attendere la scomparsa dell'avviso. L'icona del WiFi WiFi non dovrebbe più mostrare il triangolo di avvertenza e l'etichetta Senza Internet dovrebbe scomparire. Tale modifica indica che Android ha convalidato nuovamente la connessione, anziché caricare semplicemente una pagina: è questa la differenza tra un accesso completato con successo e un modulo compilato inutilmente.
5. Disattivare e riattivare il WiFi WiFi una volta se compare ancora l'indicazione "Senza Internet". Spegnere e riaccendere il WiFi WiFi prima di tentare operazioni più invasive. Una nuova connessione forza una nuova verifica ed elimina un risultato non aggiornato.

Il corretto funzionamento non balza all'occhio, ed è proprio questo l'obiettivo. La notifica scompare, la pagina desiderata si carica e le app continuano a funzionare dopo aver chiuso il browser. Se desidera creare istruzioni ripetibili per lo staff o per gli ospiti, le raccolte di guide pratiche possono aiutarla a mantenere tali passaggi in un formato facile da seguire alla reception.

Come Android stabilisce se una rete richiede l'accesso

Android non prende decisioni analizzando il browser. Invia una richiesta in background e poi valuta la risposta ottenuta.

Quando il telefono si connette a WiFi, invia una verifica HTTP in chiaro a un endpoint di connettività noto e si aspetta una risposta vuota specifica di successo. Se la rete intercetta tale richiesta e restituisce invece un reindirizzamento o una pagina di accesso, Android considera la rete come captive e mostra una richiesta di intervento. La documentazione del portale captive di Android 11 segnala che Android ha introdotto il rilevamento integrato del portale captive in Android 5.0, rilasciato nel 2014, corrispondente al APIlivello API 21, e che storicamente la verifica utilizzava connectivitycheck.gstatic.com.

Quella data è importante per gli operatori. La gestione del portale non è un trucco del browser che si aggiunge in seguito. È una funzione del sistema operativo che controlla le notifiche, le etichette di convalida e il fatto che le app ritengano o meno di essere online.

Ripartizione delle funzioni all'interno di Android

Android suddivide il lavoro. NetworkMonitor testa la raggiungibilità e lo stato del portale. L'app preinstallata Captive Portal Login mostra la pagina di autenticazione e comunica al sistema la Sua scelta.

Dopo l'accesso, Android ripete il test. Se ora il probe ha esito positivo, la rete passa allo stato convalidato e l'avviso scompare. Se non ha esito positivo, è possibile che il modulo di login sia stato completato ma non si disponga ancora di una connessione Internet utilizzabile.

Il nuovo percorso è più lineare. Una rete può pubblicizzare il proprio portale durante il DHCP utilizzando l'Opzione DHCP 114, puntando Android a un endpoint del portale captive API. Il Android riferimento NetworkCapabilities supporta il relativo lato app di questo flusso, dove Android 11 e versioni successive possono recuperare tale endpoint durante l'elaborazione DHCP e una risposta JSON con captive: true fa sì che Android presenti direttamente l'interfaccia di accesso di sistema. Se tale API non è disponibile, Android ricorre ai probe.

Per gli sviluppatori di app, il segnale si trova nel callback di rete. NET_CAPABILITY_CAPTIVE_PORTAL indica che l'ultimo probe ha rilevato un portale. NET_CAPABILITY_VALIDATED indica che la rete ha superato la convalida.

Una pagina HTTP 200 restituita dal portale non costituisce una prova dell'accesso a Internet. L'accesso va considerato riuscito solo quando la rete raggiunge uno stato convalidato.

Lettura della risposta di rete

Risposta della rete	Esito di Android	Cosa viene visualizzato
HTTP 204 dall'endpoint di verifica	Internet è aperto, nessun portale	Nessuna richiesta, la navigazione funziona
HTTP 200 con HTML del portale anziché 204	Portale captive rilevato	Viene visualizzata la notifica di accesso
Verifica bloccata, scaduta o errore DNS	Convalida non riuscita, portale non identificato	Nessuna richiesta, etichetta 'Senza internet'
JSON del captive tramite l'Opzione DHCP 114 (Android 11 e versioni successive)	Accesso richiesto	La pagina di accesso di sistema si apre direttamente
La verifica va a buon fine dopo l'accesso	Rete convalidata	L'avviso scompare e le app possono connettersi

Legga la tabella da sinistra a destra. Android non sta valutando il Suo branding, i Suoi campi del modulo o se la pagina sembra completata. Sta valutando se la risposta del probe è cambiata nel modo previsto prima dell'accesso e se torna alla normalità in seguito.

Supponiamo che il tablet di un hotel si connetta alla rete ospiti ma non mostri alcuna notifica. Lo staff spesso attribuisce la colpa alla pagina di accesso e inizia a riprogettare i pulsanti. È necessario verificare prima il probe: se la rete lo blocca, lo manda in timeout o lo lascia passare troppo liberamente, Android potrebbe non raggiungere mai lo stato captive che attiva la notifica.

Questo è il modello concettuale da mantenere. La richiesta dipende da come la rete risponde a un singolo controllo automatico. Un portale curato non può correggere la risposta errata di un probe, e una risposta corretta del probe può far sembrare affidabile anche un portale semplice.

Risolvere i problemi di accesso sul proprio telefono

Esaminare i sintomi riportati di seguito prima di modificare più impostazioni contemporaneamente. Effettuare una modifica, eseguire nuovamente il test e poi procedere oltre.

Sintomo	Causa probabile	Soluzione
Nessuna notifica di accesso dopo la connessione	Test bloccato o vecchio risultato in cache	Dissociare la rete, riconnettersi e aprire una pagina HTTP semplice nel browser
La pagina di login appare solo sui siti HTTPS	Il portale reindirizza solo le richieste HTTP semplici	Aprire una pagina HTTP per attivare il reindirizzamento
Accesso effettuato ma risulta ancora 'Senza Internet'	DNS privato o VPN bloccano la verifica	Disattivare DNS privato e VPN, quindi riattivare il WiFi WiFi
Il portale continua a ricomparire	L'indirizzo MAC casuale è cambiato per la sessione	Impostare la rete in modo da utilizzare l'indirizzo MAC del dispositivo per questa rete
La pagina di login è vuota o non invia i dati	Cache del browser obsoleta o pagina del portale non aggiornata	Cancellare la cache del browser e provare con un altro browser
Funziona su uno smartphone, ma non su un altro	Versione di Android o impostazioni di privacy diverse	Confrontare le versioni di Android ed effettuare un test disattivando l'indirizzo MAC casuale
Connessione stabilita, ma le app non funzionano	Connettività non ancora convalidata nuovamente	Attendere 30 secondi, quindi attivare e disattivare la modalità aereo

È consigliabile seguire questo ordine poiché parte dalla soluzione più semplice ed evita di ridurre la privacy, a meno che non sia strettamente necessario.

1. Attivi e disattivi WiFi, quindi dissoci la rete e si riconnetta. Questa operazione cancella il risultato di convalida memorizzato nella cache e forza un nuovo controllo.
2. Verifichi il DNS privato, la VPN e il MAC casuale. Queste impostazioni intervengono direttamente nel percorso di DNS, instradamento e identità del dispositivo, pertanto rappresentano i probabili elementi da controllare.
3. Cancelli la cache del browser o provi un secondo browser. Esegua questa operazione quando la pagina risulta vuota, caricata parzialmente o non invia i dati.

Avviso sulla privacy: la disattivazione del DNS privato o di una VPN riduce la protezione su una rete pubblica. Riattivi entrambi non appena l'accesso ha successo e non esegua operazioni bancarie o modifiche della password finché non lo ha fatto.

La riga dell'indirizzo MAC casuale è spesso fonte di inganno. Se il portale ha autorizzato un'identità MAC e lo smartphone ne presenta un'altra alla connessione successiva, la struttura rileva un nuovo dispositivo e mostra nuovamente il portale. Impostare la singola rete per l'utilizzo del MAC del dispositivo stabilizza la sessione, ma è bene non modificare tale opzione a livello globale per ogni rete.

Se nessuna di queste soluzioni funziona, eviti di ripristinare le impostazioni. Prenda nota di ora, nome della rete e modello del dispositivo, quindi fornisca tali dettagli alla struttura in modo che possa effettuare le verifiche sul lato portale. Se il problema si estende oltre l'accesso a WiFi, può trovare supporto per i problemi dello smartphone in merito a guasti più generali del dispositivo, ma un portale della struttura che non effettua mai la convalida non potrà essere risolto con un ripristino delle impostazioni di fabbrica.

Problemi noti relativi al rilevamento del portale captive

La soluzione d'istinto per un operatore è quella di autorizzare un maggior numero di domini prima del login. Tuttavia, questo approccio può compromettere completamente l'accesso al portale captive Android.

Le attuali indicazioni di Captifi relative ai portali captive che non vengono visualizzati spiegano che Android esegue controlli di connettività automatizzati che generalmente prevedono una risposta HTTP 204 da un endpoint di controllo della connettività Google; se un walled garden consente l'accesso a tale endpoint in modo troppo ampio, Android potrebbe dedurre che sia presente un accesso a Internet illimitato e disattivare la richiesta di accesso. In parole semplici, la lista di autorizzazioni può convincere lo smartphone che non sia presente alcun portale.

Questo è il compromesso che gli operatori trascurano. Una allowlist restrittiva potrebbe bloccare uno script di pagamento o un provider di identità necessario al portale. Una allowlist ampia mantiene la pagina gradevole ma rimuove il trigger che la apre.

Punti di interruzione della macchina a stati

I problemi non si presentano tutti sotto forma di notifica mancante. Gli errori DNS possono bloccare la convalida. Un'impostazione di VPN o DNS privato può aggirare il resolver della struttura. Il comportamento solo HTTPS non fornisce al portale nulla che possa reindirizzare in modo sicuro. La casualizzazione MAC può far sembrare un singolo smartphone come dispositivi diversi a ogni connessione.

Non è possibile risolvere questi problemi partendo da uno screenshot della pagina di accesso. Occorre registrare i segnali di sessione che indicano quale stato ha raggiunto Android e dove si è interrotto il processo.

• Risultato del probe: Il controllo ha restituito 204, un reindirizzamento, l'HTML del portale o nulla?
• Esito DNS: L'endpoint è stato risolto tramite il resolver della struttura?
• Stato del reindirizzamento: Il gateway ha reindirizzato il dispositivo all'URL del portale?
• Errore WebView: La schermata di accesso non è riuscita a caricarsi o a inviare i dati?
• Identità MAC casuale: Quale MAC ha autorizzato il portale?
• Validazione post-autenticazione: La rete ha concesso l'accesso dopo il completamento del modulo?

Ipotizziamo che i log mostrino i probe consentiti e un login riuscito, ma la convalida non avvenga mai. Non incolpi per primo il dispositivo. Verifichi il reindirizzamento post-login e il rilascio dell'autorizzazione, perché il portale potrebbe aver accettato il modulo senza comunicare alla rete di lasciar passare il dispositivo.

È consigliabile apportare quattro modifiche, nel seguente ordine.

1. Mantenere l'elenco di consentiti pre-autenticazione al minimo necessario al portale e ai relativi provider di accesso.
2. Registrare ciascun campo di telemetria sopra indicato per ogni sessione non riuscita e completata con successo.
3. Testare l'onboarding sicuro HTTPS in modo che gli ospiti non dipendano da un unico trigger HTTP semplice.
4. Pianificare un percorso senza portale per i dispositivi che non devono dipendere da un portale, utilizzando opzioni quali OpenRoaming WiFi, Passpoint o certificati gestiti.

Dispositivi Android gestiti e in modalità kiosk

Un tablet gestito può trovarsi su una rete che reindirizza correttamente e non mostrare comunque mai la finestra di login. Non si tratta di un problema di intensità del segnale. Di norma, è una questione di criteri.

I consigli per i consumatori presuppongono che si possa toccare le notifiche, disabilitare una VPN e modificare le impostazioni di privacy WiFi. Un utente di un kiosk spesso non può fare nulla di tutto ciò. Le linee guida per la mobilità aziendale sui portali captive per kiosk affermano che i portali captive sono gestiti da un'applicazione precaricata e che la politica del kiosk deve consentirla esplicitamente, pertanto un pacchetto di sistema per portale captive bloccato fa sì che l'accesso non si avvii mai, anche quando la rete funziona correttamente.

Questo problema si presenta nei contesti in cui nessuno considera il dispositivo come uno smartphone. Si pensi a tablet per ospedali e scuole, terminali portatili per il retail, tablet per hotel e schermi di check-in di proprietà della struttura. Lo smartphone personale dell'ospite effettua l'accesso senza problemi, pertanto il personale considera la rete ben funzionante mentre i dispositivi aziendali restano offline.

Ipotizziamo che un palmare per la vendita al dettaglio funzioni quando un responsabile testa la stessa rete sullo smartphone aziendale, ma la build del kiosk rimanga disconnessa. Verifichi la allowlist dei criteri prima di toccare il portale. Lo smartphone dimostra che il reindirizzamento esiste. Il palmare dimostra che l'immagine gestita non lo apre.

Eseguire le verifiche dell'operatore nel seguente ordine.

1. Consentire il pacchetto di sistema per portale captive nella propria politica EMM o MDM, quindi distribuire la politica e riconnettersi alla rete su un dispositivo di test.
2. Testare Android System WebView su quell'esatta immagine del dispositivo, poiché una WebView non aggiornata o disabilitata può lasciare il portale vuoto o impossibilitato all'invio.
3. Definire un percorso di onboarding alternativo per i dispositivi che non possono mostrare un portale interattivo, come un profilo preconfigurato o una connessione basata su certificato, nello spirito di un onboarding BYOD strutturato piuttosto che di una password condivisa.

Prima i criteri, poi la WebView e infine il fallback. Invertendo questo ordine, si finirà per creare soluzioni alternative per dispositivi che necessitavano solo dell'autorizzazione per visualizzare la pagina Android già rilevata.

Scegliere la struttura di un portale compatibile con Android

Iniziare con tre criteri, non con la progettazione di una splash page. La frequenza di ritorno degli ospiti, la tipologia dei dispositivi (personali o gestiti) e le versioni di Android che devono funzionare dovrebbero determinare la struttura.

Per gli ospiti occasionali, un portale captive rimane una soluzione pratica. È opportuno mantenere la elenco di autorizzazioni pre-autenticazione il più ridotta possibile, supportare i metodi di accesso attesi dagli utenti e garantire che lo sblocco post-login sia abbastanza rapido da consentire a Android di effettuare la convalida prima che l'utente inizi a modificare le impostazioni. Il nostro portale può essere aggiunto a un controller con l'URL splash e RADIUS in meno di 15 minuti, fornendo opzioni di accesso che includono SSO, Google, Apple, Facebook e SMS; la velocità di configurazione non elimina tuttavia la necessità di verificare il comportamento del test di connettività.

Per gli ospiti che ritornano, è consigliabile evitare di imporre un portale a ogni visita, se possibile. Passpoint o OpenRoaming consente a un profilo installato una sola volta di connettersi automaticamente al ritorno, senza ostacoli legati al portale e senza moduli ripetuti. Confronti questa soluzione con la Sua configurazione attuale quando analizza le soluzioni per ospiti WiFi e verifichi che il Suo controller e la Sua configurazione RADIUS supportino questa opzione prima di procedere.

Eseguire quindi i test con la prospettiva di un operatore, non di un designer.

• Versione Android più datata supportata: Confermare che la notifica venga visualizzata e che la convalida venga completata.
• Dispositivo Android attuale: Confermare che le impostazioni predefinite relative a DNS privato e MAC casuale non blocchino l'utente.
• Build per kiosk gestito: Confermare che i criteri consentano l'uso dell'app del portale e che WebView esegua il rendering della pagina.

Su ciascun dispositivo, attenda lo stato convalidato e apra due app, non solo il browser. Un solo smartphone che supera il test dimostra ben poco, poiché il rilevamento varia in base alla versione di Android, al supporto DHCP e ai criteri del dispositivo. Esegua il rollout per gli ospiti solo dopo che tutti e tre hanno superato il test.

---

Se i Suoi ospiti Android continuano a incontrare un portale che non mostra le richieste di accesso, non convalida o non mantiene la sessione avviata, Purple Access può aiutarla a gestire un portale captive personalizzato con il Suo marchio per gli utenti occasionali e Passpoint o OpenRoaming per i dispositivi che ritornano sugli access point già in Suo possesso. Ci contatti per testare il Suo dispositivo Android più datato, i Suoi dispositivi mobili attuali e qualsiasi configurazione di chiosco gestito prima del Suo prossimo rollout, garantendo che l'accesso funzioni al primo tentativo.