Suponga que usted tiene completo control programático sobre un enrutador inalámbrico (se ejecuta decir OpenWrt o DD-WRT – linux). El router está configurado para la difusión ssid, y la red está abierta.

Un usuario móvil (iPhone/Android/BB) sube.

1) en el iPhone, si el dispositivo no está actualmente wifi conectado, aparece un cuadro de diálogo que ofrece la posibilidad de conectarse a los Ssid disponibles. El usuario selecciona el ssid y se conecta. Hay una manera, desde mi router (es decir mediante Bonjour o ??) para activar el iPhone para iniciar el navegador y vuelva a cargar la página de inicio, o una configuración automática de la dirección url de forma automática?

2) cualquier respuesta diferente para Android/BB?

La razón es que en un «jardín amurallado» aplicación tengo que ser capaz de mostrar una página de bienvenida y no desea que el usuario tenga que buscar alrededor de carga de una página predeterminada primera.

Cualquier y todos los pensamientos apreciado!
Gracias
RM.

Actualización, creo que la respuesta puede estar en cualquiera de 802.21 o UMA. Leí en alguna parte que la ATT usa este con el iphone para la autenticación.

En el iPhone hay un interruptor llamado «autologin» durante la conexión a una red wifi de la puerta de enlace. Si vez que en el iPhone envía una solicitud HTTP, y recibe una redirección desde mi punto de acceso, y luego me envía a la página de bienvenida. (el lugar es totalmente abierto). El problema es que el iPhone parece estar esperando algo específico – no cambiar de ‘3G’ wi-fi y puede que el tiempo de espera. También se muestra aún el ‘inicio de Sesión’ banner acoplado a la parte superior de la ventana.

Alguien sabe de documentación para los fotogramas que tengo que enviar para hacer un correcto inicio de sesión automático?

OriginalEl autor Rob | 2010-12-15

4 Comentarios

  1. 12

    Lo que usted describe es un portal cautivo sistema (hotspot, jardín amurallado, etc). Esta funcionalidad se puede implementar con varias aplicaciones en openwrt. Echa un vistazo a otra respuesta para más detalles sobre cada opción se ofrece en openwrt Respuesta.

    Hay un par de técnicas comunes para implementar un portal cautivo

    Redirección HTTP 302

    La técnica más común es simplemente bloquear todo fuera obligado del tráfico en la red y, a continuación, redireccionar el tráfico del puerto 80 para tu propio página del portal, ya sea local o de forma remota alojada. Esta página de portal le proporcionaría los medios para «autentificar» el usuario (haciendo un agujero en el cortafuegos). Hay capa 2 métodos como el chillispot que proporcionan la misma función y que se puede autenticar contra un servidor radius si quería obtener de fantasía.

    DNS Reescribir

    Otra técnica es el uso de dns reglas para reescribir cualquier consulta dns para resolver a su propio servidor web que se presentará a continuación el usuario con una página de inicio de sesión, una vez que el usuario ha «autenticado» simplemente actualizaciones de sus dns, o permitir que el dns petición de que el usuario pase de aguas arriba.

    IP Redirigir

    Esta técnica muchas veces se solapa un poco con la redirección HTTP. Esencialmente, usted redirigir sus peticiones a una nueva dirección IP de destino. Usted puede configurar un proxy squid para luego manejar estas solicitudes.


    Tanto en dispositivos iOS y android detectará de los portales cautivos por la simple comprobación de un estándar de la URI del recurso (por ejemplo: http://www.apple.com/library/test/success.html) y si ese recurso está bloqueado, entonces usted está fuera de línea, si el recurso se presenta 302 o 307 redirigido a continuación, se supone que hay un portal cautivo en su lugar y van a abrir un navegador. Si ese recurso se encuentra a continuación, se asume que usted está en línea y no hay ningún explorador auto abierto.

    Android se abrirá el navegador estándar en el teléfono o tablet para permitir que el usuario se autentique. dispositivos iOS sin embargo abrir un pseudo navegador de internet, que es una aplicación limitada que no permite cosas como la reproducción de vídeo pop-ups, etc.

    La WISPr protocolo creo que fue originalmente diseñado para los dispositivos que no dispongan de un navegador web para que acepte los términos y condiciones y por lo tanto permitiendo que estos dispositivos de un protocolo genérico para aceptar y autenticar contra un portal cautivo. Ni siquiera estoy seguro de que el WISPr protocolo fue nunca realmente aceptado. (tal vez se vuelva a redactar)

    (No se dio cuenta de cómo este era originalmente, lo siento)

    OriginalEl autor 0xception

  2. 0

    Redirección HTTP 302

    La técnica más común es simplemente bloquear todo fuera obligado del tráfico en la red y, a continuación, redireccionar el tráfico del puerto 80 para tu propio página del portal, ya sea local o de forma remota alojada. Esta página de portal le proporcionaría los medios para «autentificar» el usuario (haciendo un agujero en el cortafuegos). Hay capa 2 métodos como el chillispot que proporcionan la misma función y que se puede autenticar contra un servidor radius si quería obtener de fantasía.

    //Trabajando en la creación de un punto de acceso wifi, que podría desencadenar automáticamente los navegadores móviles(directamente a mi tienda link) cuando el dispositivo móvil está conectado a la wifi.. Esto serviría como un factor interesante para el usuario, conseguir notado algo especial acerca de nuestro Hotspot cuando se cruzan a través de ella..

    OriginalEl autor Sarathkumar

Dejar respuesta

Please enter your comment!
Please enter your name here