En utilisant HTTP Digest authentification sur l'iPhone

Question

J'ai une application qui communique avec un serveur qui utilise l'authentification HTTP Digest.

Il me semble que la gestion « session » au sein de l'iPhone nous est assez « boîte noire » pour les développeurs. Est-il vrai que nous ne pouvons voir comment le cadre gère / sessions http persiste?

Si je suis juste ici faible, se soucierait quelqu'un pour expliquer comment gérer probablement l'authentification HTTP Digest sur l'iPhone?

Ma course de base est par:

• Faire une demande à une URL sécurisée
• Le serveur envoie un 401
• client crée et persiste un titre, et le transmet au serveur
• serveur vérifie informations d'identification, complète demande si elle est vérifiée, envoie un autre 401 sinon.
• faire une demande ultérieure d'obtenir url
autorisation
• serveur demande à nouveau ........

Cela fonctionne pour les requêtes simples, mais si je fais d'autres, les requêtes suivantes, le serveur demande à nouveau l'autorisation. Le serveur a persisté une session pour l'utilisateur particulier, mais l'iPhone ne gagne pas d'une demande dans la même session, pour une raison ... Par conséquent, le serveur doit jeter l'objet d'authentification et de créer un nouveau à chaque fois que le client fait une demande à une URL sécurisée.

Je suis sûr que ce n'est pas un comportement correct.

Si l'on regarde la façon dont un navigateur se comporte dans cette situation:

• Le navigateur demande des données URL sécurisée
• serveur envoie 401
• navigateur demande à l'utilisateur pour des titres de compétence, il persiste, il passe au serveur
• serveur vérifie des titres de compétence, les données de retour si elle est vérifiée, envoie un autre 401 sinon.
• les demandes ultérieures faites pour obtenir urls ne sont pas invités à saisir les informations d'identification parce que le navigateur gère la session.

Je crée le NSURLCredential et persistant dans le NSURLCrendtialStorage. Ensuite, lorsque l'application reçoit le « didReceiveAuthenticationChallenge » je récupère les informations d'identification du stockage et de le transmettre en arrière, créant ainsi les informations d'identification si elle n'existe pas (sur la première demande).

Toute aide serait grandement appréciée. Merci.

Answer 1

La première chose, est d'oublier les sessions HTTP, car ceux-ci n'interagissent pas avec authentification Digest logins actifs (il y a une sorte de capacité d'information de session, mais il est différent).

En effet, l'une des principales raisons d'utiliser Digest, est de ne pas avoir à utiliser des sessions juste pour maintenir un état connecté. Les séances sont lourdes et évolutivité mal.

Je ne peux pas dire avec certitude ce que votre problème est, mais je ne sais ce que je vérifie en premier lieu, ce qui est l'utilisation correcte de la création rassis et correcte de nonces.

Les agents utilisateurs ne peuvent gérer l'authentification sans requerying l'utilisateur s'ils sont invités à traiter le même nonce, ou dans un autre cas, je viendrai plus tard (plus facile à expliquer dans cet ordre).

Si vous avez le même nonce utilisé dans chaque demande, l'agent utilisateur continuera à l'utiliser avec la « HA1 » de l'utilisateur / pass pour demander des ressources suivantes. Cela se fait de manière préemptive, de sorte que le défi ne se reproduise jamais.

Bien sûr, en utilisant la même nonce introduit un élément d'insécurité, comme les attaques par rejeu deviennent trivial à toute personne qui peut renifler le trafic. Nonces devront changer régulièrement.

Par conséquent, si vous recevez une demande d'un agent utilisateur avec un en-tête d'autorisation non valide, mais la raison pour laquelle il est invalide est que le nonce est faux (il utilise un expirait) puis dans votre défi inclure « rassis = true » (par défaut à false). Ceci informe l'agent utilisateur que votre motif de rejet est le nonce est obsolète (bien sûr l'autre information peut aussi se tromper, mais cela n'a pas d'importance que vous n'allez pas laisser jouer de toute façon).

Sur réception d'un tel rassis = true l'agent utilisateur sache qu'il est pas autorisé, mais au lieu de requerying l'utilisateur (ou lancer une exception si elle est un composant d'interface utilisateur-moins) va retenter les anciens critères du nouveau nonce.

Je ne peux pas dire si tout cela est ce qui vous affecte, mais les nonces façon et caducité sont déterminés et signalaient est certainement la première chose que je regarde.

Answer 2

J'ai écrit une application iPhone avec l'authentification HTTP et expérimenté ce que vous décrivez. (Mon application utilise l'authentification de base au lieu de digérer l'authentification, mais cela ne fait pas une grande différence ici.)

La cause du problème est du côté iPhone. Le serveur doit répondre avec 401 si l'iPhone ne transmet pas les informations d'identification dans l'en-tête de requête HTTP. Et en fait, il n'a même pas si facilement pourrait une fois les informations d'identification sont stockées dans la mémoire des titres de compétence.

Ce comportement étrange a eu un effet sévère sur la vitesse de l'application puisque chaque demande fait deux allers-retours vers le serveur au lieu d'un (le premier avec le statut 401, la deuxième avec 200).

Je l'ai résolu en réglant manuellement les informations d'identification dans l'en-tête de requête 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"];

Maintenant, mon application fonctionne très bien et est très réactif.

La solution sera légèrement différente pour l'authentification Digest. Mais vous aurez l'idée.