Comportamiento del portal cautivo
A continuacion se presenta el proceso funcional del Portal cautivo:
El objetivo de este proyecto es documentar el
comportamiento del portal cautivo en los distintos dispositivos del cliente y,
con suerte, facilitar la creación de soluciones de portal cautivo que ofrezcan
una mejor experiencia para los usuarios.
Contenido
· Proceso de conexión
·
Resumen de comportamiento del dispositivo
·
Comportamiento del dispositivo
·
iOS
·
Android (Google)
·
Android (Samsung)
·
MacOS
·
Ventanas
·
ChromeOS
·
FireOS
·
Linux
· Lista de URL de comprobación de portal cautivo.
Proceso de conexión
El proceso de conexión para el CPMB generalmente implica los siguientes pasos:
Asociación de red / punto de acceso
· Comprobación del estado de conectividad (detección de red cautiva)
· Ventana emergente de una notificación (en algunos casos)
· Esperando la activación del dispositivo (si el dispositivo está en estado bloqueado)
· Abrir CPMB o esperar la activación de la notificación
· Comprobación del estado de conectividad actual en función de la acción del usuario mientras CPMB está abierto
· Cerrar CPMB después de que se complete el proceso de autenticación (automática o manual).
Proceso de conexión
El proceso de conexión para el CPMB generalmente implica los siguientes pasos:
· Asociación de red / punto de acceso
· Comprobación del estado de conectividad (detección de red cautiva)
· Ventana emergente de una notificación (en algunos casos)
· Esperando la activación del dispositivo (si el dispositivo está en estado bloqueado)
· Abrir CPMB o esperar la activación de la notificación
· Comprobación del estado de conectividad actual en función de la acción del usuario mientras CPMB está abierto
·
Cerrar CPMB después de que se complete el
proceso de autenticación (automática o manual)
Resumen de comportamiento del dispositivo (últimas versiones)
|
Plataforma |
Método de visualización del portal cautivo |
Navegador por defecto |
|
iOS |
Ventana emergente de mini navegador |
Hoja web |
|
Android |
Notificación de inserción |
Google Chrome |
|
Samsung Android |
Notificación de inserción |
Navegador de Internet Samsung |
|
MacOS |
Ventana emergente de mini navegador |
Safari |
|
Windows 10 |
Redirección manual del navegador |
Navegador preferido del usuario |
Comportamiento del dispositivo
Comportamiento general (para la mayoría de los dispositivos)
· No hay cookies persistentes en CPMB: todas las cookies escritas se destruyen después de que se cierra CPMB.
· CPMB se cierra después de completar la autorización (a veces requiere acciones adicionales del usuario)
· El CPMB desaparece y el dispositivo se desconecta de la red cuando se cambia el enfoque a otra aplicación, como SMS o correo electrónico.
· La mayoría de los servicios externos (sistema de archivos, aplicaciones, etc.) no son accesibles desde CPMB. Existen varias diferencias en el comportamiento del dispositivo en estados pre-autenticado vs post-autenticado, junto con muchas limitaciones, incluyendo el uso de memoria, almacenamiento local, soporte de Javascript, etc.
iOS (más reciente)
El flujo estándar para el proceso de autenticación de la red cautiva comienza con la asociación de Wi-Fi. No importa qué tipo de protocolo de asociación Wi-Fi se use (Hotspot 2.0 u otro), en todos los casos, justo después de que se complete la asociación, el dispositivo solicita una dirección IP (DESCUBRIMIENTO DHCP).
Después de recibir una dirección IP, el dispositivo pasa a verificar http://captive.apple.com/hotspot-detect.html(el dominio exacto y el URI podrían ser diferentes de este: consulte el apéndice para obtener una lista completa) a través del llamado CNA Helper.
En esta solicitud, el dispositivo utiliza un agente de usuario específico: "CaptiveNetworkSupport-355.200.27 wispr" (la versión mencionada podría ser diferente). La respuesta recibida se analiza para verificar si existe la autorización web y, en caso de detección, la red Wi-Fi se marca como cautiva (los interruptores apropiados aparecen en la configuración de la red), y el cambio de conexión celular a Wi-Fi no aparece de lo contrario, el dispositivo cambia a la conexión Wi-Fi como principal.
En el caso de asociación con un SSID de red cautiva conocido cuando el dispositivo no está activo (en un estado bloqueado en un bolsillo, por ejemplo), no hay más solicitudes producidas por el dispositivo antes del desbloqueo. Después de desbloquear este dispositivo, se realizan solicitudes de verificación adicionales y, en caso de que se confirme la autorización web, el CPMB aumenta.
Cuando se eleva el CPMB, genera una solicitud adicional a http://captive.apple.com/hotspot-detect.html (consulte el apéndice para obtener una lista completa) pero con diferentes tipos de User-Agent: "Mozilla / 5.0 (iPhone; CPU iPhone OS 12_0 como Mac OS X) AppleWebKit / 605.1.15 (KHTML, como Gecko) Mobile / 16A366 ”(la versión mencionada podría ser diferente). Durante el proceso de autorización en CPMB, casi todas las acciones de red seguidas de verificaciones adicionales del estado actual.
Cuando el CPMB detecta que se puede acceder al dominio cautivo, cambia el botón de control en la esquina superior derecha de "Cancelar" a "Listo" y cambia la conexión principal de la red celular a Wi-Fi. El CPMB solo realiza una verificación del dominio cautivo después de una navegación URL completa o por temporizador. Una llamada AJAX activada por JavaScript, por ejemplo, no dará como resultado que el CPMB realice una comprobación adicional del dominio cautivo. Con una aplicación de página única que no redirige a una página de destino posterior a la autenticación, debe realizarse una navegación de página completa para que el CPMB cambie el botón de control de "Cancelar" a "Listo". Si esto no sucede, el dispositivo del usuario se autenticará y se conectará a Wi-Fi, pero el CPMB solo proporcionará la opción "Cancelar",
A veces, después de varias conexiones a la red Wi-Fi sin portal cautivo con el mismo SSID que se usa en la red cautiva, iOS puede desactivar el verificador cautivo para este SSID en particular y no se elevará el navegador cautivo
iOS (con VPN)
Con VPN o algún otro software que bloquea el Detector cautivo instalado
Normalmente, hay un aumento local de notificaciones push en lugar de CPMB.
Observado en iOS 11+
iOS (con "Auto-Connect" deshabilitado)
Con el selector "Auto-connect" en la configuración de SSID de Wi-Fi apagado.
El CPMB no se muestra automáticamente. Se necesita la redirección manual desde un navegador.
Observado en iOS
6+
Android (Google)
· El sistema operativo Android determina la existencia del portal cautivo al intentar acceder a una lista de dominios (consulte el apéndice para obtener una lista completa). Si los dominios son accesibles, se puede suponer que no está limitado por un portal cautivo. De lo contrario, activará la notificación.
· Al hacer clic, los usuarios son redirigidos a CPMB.
· Experiencia PostAuth: una vez que un usuario se ha autenticado con éxito, el mini navegador puede ocultarse de forma automática o manual presionando un botón.
Android (Samsung)
Active Captive Portal: notifica al usuario sobre la necesidad de iniciar sesión presionando el mini navegador de nivel OS.
El sistema operativo Android determina la existencia del portal cautivo al intentar acceder a una lista de dominios (consulte el apéndice para obtener una lista completa). Si los dominios son accesibles, se puede suponer que no está limitado por un portal cautivo. De lo contrario, aparecerá el portal cautivo o el navegador completo.
Experiencia posterior a la autenticación: una vez que un usuario se ha autenticado con éxito, el mini navegador puede ocultarse de forma automática o manual presionando un botón especial.
Puede ser un bloqueo de anuncios artificial en CPMB en algunos dispositivos Android.
MacOS
Mini-navegador nativo - AKA "Captive Network Assistant" (CNA) - Notifica al usuario sobre la necesidad de iniciar sesión presionando el mini navegador a nivel del sistema operativo.
Muestra una ventana del navegador de 900 px de ancho por 572 px de alto
Los métodos Javascript window.alert () y window.confirm () no funcionan
Chrome OS
Connection Manager para Chrome OS intenta recuperar la página web http://clients3.google.com/generate_204 . Se sabe que esta conocida URL devuelve una página vacía con un estado HTTP 204. Si por alguna razón no se devuelve la página web o se recibe una respuesta HTTP distinta de 204, entonces marcará el servicio como en el estado del portal.
Otros portales cautivos, a veces administrados por operadores de telefonía celular, no proporcionan absolutamente ninguna conectividad IP que no sea a sus propios servidores, pero utilizan un servidor DNS estándar y no interceptan las solicitudes HTTP. Cuando un Chrome Book se conecta a este tipo de red, las solicitudes HTTP fallan porque la conexión TCP a clients3.google.com nunca se puede establecer. El código del portal intenta varias veces durante hasta 10 segundos conectarse a clients3.google.com. Si no puede conectarse, marca el servicio como si estuviera en un portal cautivo. Esta determinación es poco confiable porque las conexiones de latencia muy alta, las conexiones con pérdida y otros problemas de red también pueden provocar la falla para conectarse a clients3.google.com. Todos estos son indicativos de una red que no es completamente funcional, pero no necesariamente indican que la máquina está atrapada en un portal cautivo.
Windows 10
Notifica al usuario sobre la necesidad de iniciar sesión abriendo el navegador predeterminado del usuario e intentando redirigirlo a un destino HTTP predeterminado que la red debe interceptar.
Ubuntu
Hasta ahora, no admite el inicio de sesión en el portal cautivo a nivel de sistema operativo en versiones LTS disponibles (soporte a largo plazo) Ahora hay una discusión en la sección de redes de Ubuntu WiKi donde se propone proporcionar soporte a nivel de sistema operativo en las próximas versiones. GNOME (GNU Network Object Model Environment) había introducido un aviso de inicio de sesión automático para portales cautivos Wi-Fi (puntos de acceso Wi-Fi que requerían inicio de sesión basado en la web, como los que se encuentran en lugares públicos) hace bastante tiempo. Sin embargo, esta funcionalidad aún no está disponible en Ubuntu GNOME. Lo mismo forma parte de la lista de deseos en los próximos lanzamientos de Ubuntu LTS.
Linux (navegador Firefox instalado)
Firefox introduce la detección automática de portales cautivos y notifica al usuario sobre la necesidad de iniciar sesión. Además, después de que Firefox detecta un portal cautivo, reemplaza las páginas de error del certificado con un mensaje que alienta al usuario a iniciar sesión.
Firefox determina la existencia de una restricción de portal cautivo al intentar descargar el archivo success.txt desde http://detectportal.firefox.com/success.txt (solo hay una palabra en ese archivo, la palabra "éxito". puede recuperar con éxito ese archivo, puede suponer que no está restringido por un portal cautivo, de lo contrario, activará una notificación en el navegador.
Linux (navegador Chrome instalado)
Chrome introduce la detección automática de portales cautivos y notifica al usuario sobre la necesidad de iniciar sesión. Además, después de que Chrome detecta un portal cautivo, reemplaza las páginas de error del certificado con un mensaje que alienta al usuario a iniciar sesión.
FireOS
Fire OS (basado en Android) utiliza http://spectrum.s3.amazonaws.com/kindle-wifi/wifistub.html para las comprobaciones de conectividad y si no se puede acceder al URI, aparece una notificación que indica que se requiere un inicio de sesión en el portal cautivo.
Al tocar las notificaciones, se abre el mini navegador del portal cautivo, el dispositivo intenta comunicarse con http://spectrum.s3.amazonaws.com/kindle-wifi/wifiredirect.html y el usuario es recibido con "Conexión no segura". Esta conexión no es segura. Cuando se utiliza una conexión no segura, su información personal puede ser visible para otros”. Después de hacer clic en continuar, se carga el portal cautivo.
La advertencia de Conexión no segura parece ser activada por el intento de llegar a la página "wifiredirect" a través de HTTP, no debido a una falta de coincidencia del certificado TLS.
Lista de URL de verificación de portal cautivo
Apple iOS
captive.apple.com
apple.com
Apple MacOS
captive.apple.com
Google Android
clients3.google.com
clients4.google.com
android.clients.google.com
connectivitycheck.android.com
connectivitycheck.gstatic.com
Samsung Android
http://connectivitycheck.android.com/generate_204
http://connectivitycheck.gstatic.com/generate_204
d2uzsrnmmf6tds.cloudfront.net
HTC Android
clients3.google.com
Ventanas
msftncsi.com
Related Articles
Funcionalidades del portal cautivo
El portal cautivo permite integrar validaciones con métodos externos y personalizar la experiencia de manera que se ajuste a las necesidades, para esto se cuenta con recursos dentro de las configuraciones para este. Estas configuraciones se ...Portal Cautivo
El portal cautivo es una herramienta de control implementada generalmente en las redes WiFi públicas y está orientada a la interacción con los usuarios con el fin de mostrar o recolectar información. Aunque la mayoría de las marcas de AP’s y ...Comportamiento notificaciones automáticas
PUSH NOTIFICATIONS A continuación se detalla el análisis de ingeniería realizado para estudiar la causa por la cual “no se muestra la notificación al usuario sobre la necesidad de una acción en la red wifi, luego de la finalización de la sesión”. ...Configuración necesaria para el despliegue del portal
Aunque el portal cautivo es una herramienta robusta y con muchas funcionalidades, hay una configuración básica que se requiere para que los usuarios puedan ver el portal, interactuar con él, y autenticarse correctamente. Del lado del equipo de red, ...Pasos de conexion y uso portal cautivo
Conexión y Uso del portal cautivo (usuario final) 1. El usuario se debe conectar a la red Wifi proporcionada por el cliente, se recomienda que el anfitrión de la Red tenga algunas imágenes o avisos indicándole el nombre de la Red al Usuario a la ...