2012-08-14 16 views
15

Mi universidad tiene un punto de acceso wifi abierto, sin embargo, requiere que ingrese su correo electrónico antes de que le permita usar la web. Mi problema es que el Wifi es estúpido porque parece desconectar mi conexión y me obliga a ingresar mi correo electrónico nuevamente cada 10 minutos.Android - Detectar si Wifi Requiere Acceso del navegador

Quería crear mi propia aplicación que puedo usar para hacer este paso automáticamente para mí, pero parece que no encuentro ninguna documentación que permita detectar fácilmente si un punto de acceso Wifi tiene una página de inicio de sesión del navegador. ¿Hay alguna forma en Android para obtener esta información, o solo para ver si mi conexión a algo siempre se redirige a 1.1.1.1?

+0

Envíe una solicitud HTTP a google.com y vea qué sucede. – SLaks

Respuesta

15

Consulte la sección "Gestión de Red Sign-On" de the HttpUrlConnection documentation:

Algunas redes Wi-Fi bloquear el acceso a Internet hasta que el usuario hace clic a través de un inicio de sesión en la página. Dichas páginas de inicio de sesión normalmente se presentan mediante el uso de redireccionamientos HTTP. Puede usar getURL() para probar si su conexión ha sido redirigida inesperadamente. Esta comprobación no es válida hasta después de que se hayan recibido los encabezados de respuesta, que puede desencadenar llamando a getHeaderFields() o getInputStream().

Tienen un fragmento de código de muestra allí. No puedo decir si esto cubrirá tu WiFi AP en particular, pero vale la pena intentarlo.

+1

Implementé esto y funciona bien cuando la redirección cambia el nombre de host, pero otros no. Por ejemplo, este enrutador de Belkin deja todo lo que escribió en el navegador tal como está, pero aún muestra su propia página. urlConnection.getUrl(). getHost() devuelve lo que debería debido a esto. ¿Alguna sugerencia en ese caso? ¿Cómo detecta Android la conectividad? Es decir. los iconos naranja/blanco naranjas/blancos. – Flyview

+0

¿No hay otra forma de validar esto? Este enfoque es propenso a errores. El ejemplo es lo que @Flyview describió. Su enfoque a continuación también es propenso a errores (ver comentarios en la respuesta a continuación). – neteinstein

+0

@NeTeInStEiN: "Este enfoque es propenso a errores", eso dependerá de las circunstancias, supongo. Por definición, no es posible manejar el escenario de Flyview en general, ya que una respuesta '200 OK' del portal cautivo para la URL es indistinguible (nuevamente, en general) de una respuesta' 200 OK' del sitio real afectado. Con HTTPS, puede verificar certificados para ver si es el servidor correcto o no, y esa debería ser una prueba más definitiva. – CommonsWare

3

Haga ping a una dirección IP externa (como google.com) para ver si responde.

try { 
     Runtime runtime = Runtime.getRuntime(); 
     Process proc = runtime.exec("ping -c 1 " + "google.com"); 
     proc.waitFor();  
     int exitCode = proc.exitValue(); 
     if(exitCode == 0) { 
      Log.d("Ping", "Ping successful!"; 
     } else { 
      Log.d("Ping", "Ping unsuccessful."); 
     } 
    } 
    catch (IOException e) {} 
    catch (InterruptedException e) {} 

El único inconveniente es que esto también indicaría que se requiere un inicio de sesión web cuando simplemente no hay conexión a Internet en el punto de acceso Wi-Fi.

@CommonsWare Creo que esta es una mejor respuesta que abrir una UrlConnection y verificar el host, ya que el host no siempre cambia incluso cuando se muestra la página de redirección. Por ejemplo, probé en un enrutador Belkin y deja todo lo que escribió en el navegador tal como está, pero aún muestra su propia página. urlConnection.getUrl(). getHost() devuelve lo que debería debido a esto.

+0

Esto tampoco soluciona el problema, ya que cuando se conecta puede necesitar iniciar sesión, pero después de un tiempo inicie sesión a través de la página web, y cuando lo haga no recibirá ningún evento que le avise que algo ha cambiado para que pruebe su conectividad nuevamente ... – neteinstein

0

El problema podría ser, al menos hoy, que las versiones más nuevas de Android (5.1+?) Mantengan la conexión 3G/4G en funcionamiento hasta que el inicio de sesión wifi realmente conduzca a una conexión wifi totalmente funcional.

No lo he probado, pero tal vez con el valor enum CAPTIVE_PORTAL_CHECK de NetworkInfo s DetailedState se puede tratar de detectar este modo correctamente?

+1

CAPTIVE_PORTAL_CHECK es un estado transitorio y el estado final se CONECTARÁ incluso si estás conectado a un Wifi cautivo. La forma (que funcionó para mí) de comprobar si hay Wifi cautivo es tratar de conectarse a un sitio web y verificar si se lo redirige a otra url. – rsc

1

Creo que @FlyWheel está en el camino correcto, pero yo usaría http://clients1.google.com/generate_204 y si no obtiene un 204, sabrá que está detrás de un portal cautivo. Puede ejecutar esto en un bucle hasta que obtenga 204, en cuyo caso sabrá que ya no está detrás de un portal cautivo.

@FlyWheel escribió: El único inconveniente es que esto también indicaría que se requiere un inicio de sesión web cuando simplemente no hay conectividad a Internet en el punto de acceso WiFi.

Puede resolver esto registrando un receptor en android.net.conn.CONNECTIVITY_CHANGE. Puede verificar si Wifi está ENCENDIDO y está conectado mirando el Estado Suplicante de la conexión.

Aquí hay un fragmento, pero yo no ejecutarlo:

WifiManager wm = (WifiManager) context.getSystemService(Context.WIFI_SERVICE); 
WifiInfo wifiInfo = wm.getConnectionInfo(); 
SupplicantState suppState = wifiInfo.getSupplicantState(); 

if (wm.isWifiEnabled()) { 
    if (suppState == SupplicantState.COMPLETED){ 
     // TODO - while loop checking generate_204 (FlyWheels code)Using intent service. 
    } 
} 

No puedo recordar si el SupplicantState se completa o asociadas, se tendrá que comprobar que. Debería usar un servicio de intendencia para verificar la generación_204, ya que los receptores de difusión tienen una corta vida útil.

Cuestiones relacionadas