Uso de la autenticación implícita HTTP en el iPhone

Question

Tengo una aplicación que se comunica con un servidor que utiliza autenticación HTTP Digest.

Me parece que la gestión de 'sesiones' dentro del iPhone es una especie de "caja negra" para nosotros, los desarrolladores.¿Es cierto que no podemos ver cómo el marco maneja/persiste las sesiones http?

Si estoy siendo poco claro aquí, ¿alguien le importaría explicar cómo manejar probablemente la autenticación HTTP Digest en el iPhone?

Mi recorrido básico es:

• Realizar una solicitud a una URL segura
• El servidor envía un 401
• El cliente crea y conserva una credencial y la devuelve al servidor.
• El servidor verifica la credencial, completa la solicitud si se verifica, envía otro 401 si no.
• realizar una solicitud posterior para asegurar la URL
• el servidor solicita autorización nuevamente.....

Esto funciona para solicitudes únicas, pero si realizo solicitudes adicionales posteriores, el servidor solicita autorización nuevamente.El servidor ha mantenido una sesión para el usuario en particular, pero el iPhone no realiza una solicitud dentro de la misma sesión por algún motivo...Por lo tanto, el servidor debe descartar el objeto de autenticación y crear uno nuevo cada vez que el cliente realiza una solicitud a una URL segura.

Estoy seguro de que este no es un comportamiento correcto.

Si miramos cómo se comporta un navegador en esta situación:

• El navegador solicita datos desde una URL segura
• el servidor envía 401
• El navegador solicita al usuario la credencial, la conserva y la pasa al servidor.
• El servidor verifica la credencial, devuelve datos si se verifican, envía otro 401 si no.
• A las solicitudes posteriores realizadas a direcciones URL seguras no se les solicitan credenciales porque el navegador administra la sesión.

Estoy creando NSURLCredential y manteniéndolo dentro de NSURLCrendtialStorage.Luego, cuando la aplicación recibe el 'didReceiveAuthenticationChallenge', recupero la credencial del almacenamiento y la devuelvo, creando la credencial si no existe (en la primera solicitud).

Cualquier ayuda sería muy apreciada.Gracias.

Answer 1

Lo primero es olvidarse de las sesiones HTTP, ya que estas no interactúan con los inicios de sesión activos de autenticación implícita (existe una especie de capacidad de información de sesión, pero es diferente).

De hecho, una de las razones principales para usar Digest es no tener que usar sesiones solo para mantener un estado de inicio de sesión.Las sesiones son pesadas y perjudican la escalabilidad.

No podría decir con certeza cuál es su problema, pero sí sé qué verificaría primero, que es el uso correcto de elementos obsoletos y la creación correcta de nonces.

Los agentes de usuario solo pueden manejar la autenticación sin volver a consultar al usuario si se les pide que manejen el mismo nonce, o en otro caso, lo abordaré más adelante (es más fácil explicarlo en este orden).

Si utiliza el mismo nonce en cada solicitud, entonces el agente de usuario continuará usándolo junto con el "ha1" del usuario/pase para solicitar recursos posteriores.Esto se hace de forma preventiva, por lo que el desafío nunca ocurre.

Por supuesto, usar el mismo nonce introduce un elemento de inseguridad, ya que los ataques de repetición se vuelven triviales para cualquiera que pueda rastrear el tráfico.Los nonces tendrán que cambiar periódicamente.

Por lo tanto, si recibe una solicitud de un agente de usuario con un encabezado de Autorización no válido, pero la razón por la que no es válido es que el nonce es incorrecto (está usando uno vencido), entonces en su desafío incluya "stale=true" (el valor predeterminado es FALSO).Esto informa al agente de usuario que el motivo del rechazo es que el nonce está desactualizado (por supuesto, la otra información también puede ser incorrecta, pero eso no importa, ya que no permitirá que se reproduzca de ninguna manera).

Al recibir un valor obsoleto = verdadero, el agente de usuario sabrá que no está autorizado, pero en lugar de volver a consultar al usuario (o generar una excepción si se trata de un componente sin interfaz de usuario), volverá a intentar los criterios anteriores con el nuevo nonce.

No puedo decir si algo de esto es lo que te está afectando, pero la forma en que se determinan y señalan los nonces y el estancamiento es sin duda lo primero que miraría.

Answer 2

He escrito una aplicación para iPhone con la autenticación HTTP y experimentado lo que usted describe. (Mi aplicación utiliza la autenticación básica en lugar de la autenticación implícita, pero eso no lo hace una gran diferencia en este caso.)

La causa del problema está en el lado iPhone. Se requiere que el servidor para responder con 401 si el iPhone no envía las credenciales en la cabecera de petición HTTP. Y de hecho no lo hace a pesar de que podría fácilmente una vez que la credencial se almacena en el almacenamiento de credenciales.

Este comportamiento extraño tenía un efecto severo en la velocidad de la aplicación, ya que cada petición causó dos viajes de ida y vuelta al servidor en lugar de uno (el primero con el estado 401, el segundo con 200).

He resuelto por la configuración manual de las credenciales en el encabezado de la solicitud HTTP:

NSString* credentials = [NSString stringWithFormat: @"%@:%@", usr, pwd];
const char* credentialsChars = [credentials cStringUsingEncoding: NSUTF8StringEncoding];
credentials = [CommunicationUtil stringBase64WithData: (const UInt8*) credentialsChars length: strlen(credentialsChars)];
NSString* authorizationHeader = [NSString stringWithFormat: @"Basic %@", credentials];

NSMutableURLRequest* request =
    [[NSMutableURLRequest alloc] initWithURL: url 
        cachePolicy: NSURLRequestReloadIgnoringLocalCacheData
        timeoutInterval: 15];

    [request setValue: authorizationHeader forHTTPHeaderField: @"Authorization"];

Ahora mi aplicación funciona muy bien y es muy sensible.

La solución se verá ligeramente diferente para la autenticación implícita. Sin embargo, usted consigue la idea.