Popup del portale captive: la guida definitiva [chiuso]


12

Sto implementando manualmente un portale captive WiFi. Ho praticamente tutto funzionato MA un singolo intoppo: voglio che tutti vedano il popup del portale captive dei loro sistemi operativi mobili (o sistemi operativi per computer) per un'esperienza impeccabile.

Dal momento che ognuno di loro ha il suo modo contorto di farlo, sono apparentemente incapace di ottenere un'esperienza multipiattaforma coerente.

Per far sì che ciò accada, posso avere qualche aiuto per descrivere (1) quali richieste URL dai client WiFi devono essere reindirizzate a una pagina di accesso e / o (2) quale configurazione del server web nginx o apache può essere utilizzata per reindirizzare WiFi clienti a una pagina di accesso?

La mia pagina di accesso al portale captive in questo esempio è http: //captiveportal.lan . Ecco alcuni dei sistemi operativi per cui sto cercando di risolvere questo problema.


Android 4/5/6

  • Apache:
    RedirectMatch 302 /generate_204 http://captiveportal.lan
  • nginx:?

Versioni precedenti di Android

  • Apache:?
  • nginx:?

iOS 8

  • Apache .htaccess:
    RewriteEngine on
    RewriteCond %{HTTP_USER_AGENT} ^CaptiveNetworkSupport(.*)$ [NC]
    RewriteRule ^(.*)$ http://captiveportal.lan [L,R=302]

  • nginx:?

Versioni precedenti di iOS

  • Apache:?
  • nginx:?


Windows Phone

  • Apache:
    RedirectMatch 302 /ncsi.txt http://captiveportal.lan
  • nginx:?


Windows 7 \ 8 \ 10

  • Apache: vedi windows phone (funziona su win7).
  • nginx:?

Mac OS

  • Apache:?
  • nginx:?

Amazon Kindle - ha un popup?

  • Apache:?
  • nginx:?

5
No, non è troppo ampio, è semplicemente un problema multipiattaforma. Il problema più multipiattaforma che ci può essere, forse. Ha anche raggiunto lo stato di "domanda notevole" (più di 2500 visualizzazioni), quindi le persone sono davvero interessate e stai rendendo un enorme disservizio a tutti impedendo ai contributi di riversarsi. Per la vergogna!
ppparadox,

Grazie mille per il post; mi ha permesso di fare questo unix.stackexchange.com/questions/386242/…
Rui F Ribeiro

Risposte:


5

Tutti i sistemi operativi mobili controllano semplicemente una pagina Web per decidere se si trovano dietro un portale captive o meno.

Il meccanismo è questo:

  1. OTTIENI / INVIA http://foo.com/bar.html
  2. Se bar.html == [contenuto previsto]> Apri Internet
  3. If bar.html! = [Contenuto previsto]> Captive Portal
  4. If bar.html [status]! = SUCCESS> Nessuna rete

Inoltre, per iOS, è necessario disporre di un dominio per la rete WiFi in quanto presuppone che una rete senza dominio senza accesso sia una rete domestica e lo contrassegni semplicemente come Nessuna rete anziché Captive Portal.

Assicurati di reindirizzare esplicitamente i seguenti URL sul tuo portale captive con HTTP Success:

Android / Chromebook:

  • clients3.google.com

iOS 6:

  • gsp1.apple.com
  • * .akamaitechnologies.com

iOS 7:

  • www.appleiphonecell.com
  • www.airport.us
  • * .apple.com.edgekey.net
  • * .akamaiedge.net
  • * .akamaitechnologies.com

iOS 8/9:

finestre

  • ipv6.msftncsi.com
  • www.msftncsi.com

Molti fornitori hanno anche iniziato a utilizzare l'agente utente "CaptiveNetworkSupport", sebbene non sia così comune come il metodo URL sopra. Basta controllare che UA e dare sempre la tua pagina del portale ... però non funziona al 100%.

Uso il metodo URL e ha funzionato bene.


Ti interessa condividere alcuni server Web funzionanti conf \ firewall rules \ php snippet che usi per ottenere il popup?
ppparadox,

Sembra che Android v6 stia utilizzando un URL diverso. connectivitycheck.gstatic.com che è menzionato qui
David T

Perché dovresti reindirizzare esplicitamente gli URL di prova? Non servirebbe solo la pagina di accesso per ogni URL fino a quando l'utente non ha effettuato l'accesso?
AShelly,

2

Amazon Kindle (Fire)

Amazon Kindle (Fire) presenta la seguente richiesta e, se non può essere recuperato "... presuppone che l'utente debba effettuare il login e solleva una schermata di accesso.":

iOS 8.4

Per l'ultimo iOS ho dovuto abbinare tutti gli URI per le richieste a http://captive.apple.com - non solo "/hotspot-detect.html".

I client iOS 8.4 stanno effettuando richieste con URI generati casualmente (ad es. "/xmqPyZUv/3r8jTjv8.html" e "/7exN0TV7q0COX0/eKlBU8baU2tape/fjXUzDHBdE6W0O/BGbw7TYH2DBTTBt.html)


1
IOS 8.4 imposta UserAgent su "CaptiveNetworkSupport"? Ti interessa condividere alcuni server Web funzionanti conf \ firewall rules \ php snippet che usi per ottenere il popup? Inoltre, perché qualcuno ti ha sottovalutato senza preoccuparsi di spiegare perché? Stupide ...
ppparadox,

La stringa agente esatta è "CaptiveNetworkSupport-277.10.5 wispr". Quando reindirizzerò queste richieste (elencate in questa domanda) a una pagina di accesso, Apple iOS aprirà una pagina di accesso e Android mostrerà una barra di intestazione di accesso. Dopo aver eseguito correttamente l'accesso alla pagina di accesso, il sistema del portale captive deve consentire il buon esito di queste richieste HTTP affinché la finestra popup e la barra di accesso scompaiano. Ho testato con successo questo in un portale captive personalizzato che ho creato utilizzando solo server httpd Linux, dnsmasq e Apache.
Russell E Glaue,

Hai dimenticato di chiedere se Kindle imposta anche quell'agente utente.
ppparadox,

1
Per kindle vedo "Dalvik / 2.1.0 (Linux; U; Android 5.0.1; VS985 4G Build / LRX21Y)" (forse è un'app kindle?). Questo thread mobileread.com/forums/showthread.php?t=188439 dice "Mozilla /5.0 (Linux; come iPhone; U; en-US) AppleWebKit / 528.5 + (KHTML, come Gecko, Safari / 528.5 +) Versione / 4.0 "
Russell E Glaue,

1
@ppparadox Non so perché ho ottenuto il voto negativo pochi secondi dopo aver pubblicato. Se ti piace il mio contributo, per favore dammi un voto. Grazie.
Russell E Glaue,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.