iOS: Comment puis-je recevoir HTTP 401 au lieu de -1012 NSURLErrorUserCancelledAuthentication
J'ai un problème similaire à celui décrit dans le lien ci-dessous.
NSHTTPURLResponse statusCode est de retour à zéro quand il doit être 401
- Je utiliser [NSURLConnection sendSynchronousRequest:returningResponse:error:]
pour obtenir des données à partir d'un serveur.
Quand NSURLConnection reçoit le Code HTTP 401, elle ne retourne rien, mais un objet d'erreur avec le code -1012
de la NSURLErrorDomain. -1012
correspond à NSURLErrorUserCancelledAuthentication
. Depuis que j'ai à analyser l'en-Tête HTTP, je dois obtenir l'erreur d'origine et non pas ce NSURLConnection fait hors de lui.
Est-il un moyen de recevoir l'original 401 http paquet?
- Je rencontre exactement le même problème.
- Avez-vous regardé dans ASIHTTPRequest?
- Je préfère rester avec construit-dans l'Api si possible. FWIW, la vérification de la
NSError
hors-param pourNSURLErrorUserCancelledAuthentication
fonctionne très bien. Il semble juste bizarre que lorsqu'un état 401 est retourné, leNSURLResponse
hors-param gauche est nul.
Vous devez vous connecter pour publier un commentaire.
Oui. Cessez d'utiliser l'API synchrones. Si vous utilisez l'asynchrone en fonction de délégué de l'API, puis vous avez beaucoup plus de contrôle sur la connexion. Avec cette API, sauf dans les cas où une erreur s'est produite avant l'en-tête HTTP est reçu, vous toujours recevoir
-connection:didReceiveResponse:
, qui vous donne accès à l'en-tête HTTP champs (encapsulé dans unNSURLResponse
objet). Vous pouvez également mettre en place l'authentification selon le délégué méthodes si vous êtes si incliné.NSURLRequest
avant l'envoi de la première fois. Tout ce que je besoin de retour est le code de réponse et, éventuellement, le (très court) le corps de la réponse de données. Cette demande est également l'un de plusieurs étapes successives dans mon algorithme, et de faire de l'asynchrone moyen serait que la séquence de beaucoup moins claire.Solution de contournement:
N'est pas la meilleure solution, mais ça marche!!!
if (error.code == kCFURLErrorUserCancelledAuthentication) statusCode = 401;
if (error.code == NSURLErrorUserCancelledAuthentication)
?Je suis surpris de voir le "recommandé" la réponse à ce fil.
Bien, j'en suis sûr, à l'aide de la version asynchrone méthodes sont mieux, mais ça n'explique toujours pas pourquoi le
sendSynchronousRequest
fonction ne vous permettent de passer d'une variable à retourner le code de réponse, mais, dans certaines circonstances, elle retourne néant.Il 4 ans depuis que ce problème a été signalé, je suis en utilisant XCode 6.2 avec iOS 8.2, et cet ancien bug est toujours présent.
Mes services web délibérément retourner une erreur 401 lorsqu'un nom d'utilisateur & mot de passe ne sont pas corrects.
Quand mon iPhone app appels ce service (avec le mauvais titres)...
..
response
est retourné comme nulle (donc je ne peut pas de test pour la Réponse HTTP 401),error
reçoit un -1012 message enveloppé comme ceci:et la
sendSynchronousRequest
fonction renvoie une longue chaîne XML contenant... bien... ce...Venir sur Apple, fixer vos bugs...
Ses effectivement arrêter simple. Maintenant il est vrai que la demande asynchrone est en fait une assez bonne aide. Mais vous devez garder à l'esprit que c'est juste une aide. Http est juste un protocole pour la mise en réseau et à cet effet, il ne DOIT pas interagir avec l'utilisateur. En d'autres termes, les deux cas sont en fait une seule et même chose.
Si vous ne souhaitez pas utiliser le asynch helper que je vous suggère de montrer à l'utilisateur une boîte de dialogue de connexion et de répéter votre demande jusqu'à ce que l'utilisateur appuie sur annuler.
[modifier]
juste pour info, personnellement je préfère curl. Fonctionne comme un charme presque partout 😉
J'ai été confronté à la question de ne pas recevoir 401 Unauthorized code d'erreur (devenait nulle réponse aussi didReceiveResponse méthode n'était pas appelé) au lieu de recevoir -999 annulation de l'erreur. L'erreur que je faisais dans mon code est:
Dans didReceiveChallenge: méthode du délégué,
La NSURLSessionAuthChallengeCancelAuthenticationchallenge a été entraînant la -999 d'erreur et il n'y a pas de réponse 401 obtenus.
Au lieu de cela lorsque j'ai utilisé completionHandler (NSURLSessionAuthChallengePerformdefaulthandling, nil); j'ai été reçu réponse 401 dans didReceiveResponse: méthode du délégué comme prévu.
Note de iOS documentation https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/URLLoadingSystem/NSURLSessionConcepts/NSURLSessionConcepts.html, Si nous annulons le urlsession ensuite, il est indiqué comme annulée, mais pas comme d'erreur 401 en réponse.