iOS: как я могу получить HTTP 401 вместо -1012 NSURLErrorUserCancelledAuthentication
У меня проблема, аналогичная той, которая описана в ссылке ниже.
NSHTTPURLResponse statusCode возвращает ноль, когда оно должно быть 401
я использую [NSURLConnection sendSynchronousRequest:returningResponse:error:]
получить данные с сервера.
Когда NSURLConnection получает HTTP-код 401, он не возвращает ничего, кроме объекта ошибки с кодом -1012
от NSURLErrorDomain. -1012
соответствует NSURLErrorUserCancelledAuthentication
, Так как мне нужно проанализировать HTTP-заголовок, мне нужно получить исходную ошибку, а не то, что NSURLConnection сделал из нее.
Есть ли способ получить оригинальный http-пакет 401?
5 ответов
Да. Прекратите использовать синхронный API. Если вы используете асинхронный API на основе делегатов, тогда у вас будет намного больше контроля над соединением. С этим API, за исключением случаев, когда возникает ошибка до получения заголовка HTTP, вы всегда будете получать -connection:didReceiveResponse:
, который дает вам доступ к полям заголовка HTTP (инкапсулирован в NSURLResponse
объект). Вы также можете реализовать аутентификацию, используя соответствующие методы делегата, если вы так склонны.
Временное решение:
[NSURLConnection sendAsynchronousRequest:request queue:[NSOperationQueue new] completionHandler:^(NSURLResponse *response, NSData *data, NSError *connectionError) {
NSHTTPURLResponse *aResponse = (NSHTTPURLResponse *)response;
int statusCodeResponse = aResponse.statusCode;
NSString *strError = [NSString stringWithFormat:@"%@", [connectionError description]];
if ([strError rangeOfString:@"Code=-1012"].location != NSNotFound) {
statusCodeResponse = 401;
}
Это не лучшее решение, но оно работает!
Я удивлен "рекомендуемым" ответом на эту тему.
Хорошо, я уверен, что использование асинхронных методов лучше, но это не объясняет, почему sendSynchronousRequest
Функция позволяет передавать переменную для возврата кода ответа, но в некоторых случаях она просто возвращает nil.
Прошло 4 года с тех пор, как об этой проблеме сообщили, я использую XCode 6.2 с iOS 8.2, и эта древняя ошибка все еще присутствует.
Мои веб-службы намеренно возвращают ошибку 401, когда имя пользователя и пароль пользователя не верны.
Когда приложение для iPhone вызывает эту службу (с неверными учетными данными)...
NSHTTPURLResponse *response = nil;
NSData *data = [ NSURLConnection sendSynchronousRequest:request returningResponse:&response error:&error ];
.. response
возвращается как ноль (поэтому я не могу проверить HTTP Response 401), error
получает сообщение -1012, завернутое так:
Error Domain=NSURLErrorDomain Code=-1012 "The operation couldn’t be completed. (NSURLErrorDomain error -1012.)"
UserInfo=0x174869940 {NSErrorFailingURLStringKey=https://mywebservice.com/Service1.svc/getGroupInfo/6079, NSUnderlyingError=0x174e46030
"The operation couldn’t be completed. (kCFErrorDomainCFNetwork error -1012.)",
NSErrorFailingURLKey=https://mywebservice.com/Service1.svc/getGroupInfo/6079}
и sendSynchronousRequest
Функция возвращает длинную строку XML, содержащую... ну... это...
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Request Error</title>
<style>BODY { color: #000000; background-color: white; font-family: Verdana; margin-left: 0px; margin-top: 0px; } #content { margin-left: 30px; font-size: .70em; padding-bottom: 2em; } A:link { color: #336699; font-weight: bold; text-decoration: underline; } A:visited { color: #6699cc; font-weight: bold; text-decoration: underline; } A:active { color: #336699; font-weight: bold; text-decoration: underline; } .heading1 { background-color: #003366; border-bottom: #336699 6px solid; color: #ffffff; font-family: Tahoma; font-size: 26px; font-weight: normal;margin: 0em 0em 10px -20px; padding-bottom: 8px; padding-left: 30px;padding-top: 16px;} pre { font-size:small; background-color: #e5e5cc; padding: 5px; font-family: Courier New; margin-top: 0px; border: 1px #f0f0e0 solid; white-space: pre-wrap; white-space: -pre-wrap; word-wrap: break-word; } table { border-collapse: collapse; border-spacing: 0px; font-family: Verdana;} table th { border-right: 2px white solid; border-bottom: 2px white solid; font-weight: bold; background-color: #cecf9c;} table td { border-right: 2px white solid; border-bottom: 2px white solid; background-color: #e5e5cc;}</style>
</head>
<body>
<div id="content">
<p class="heading1">Request Error</p>
<p>The server encountered an error processing the request. The exception message is 'Access is denied.'. See server logs for more details. The exception stack trace is: </p>
<p> at System.ServiceModel.Dispatcher.AuthorizationBehavior.Authorize(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage11(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)</p>
</div>
</body>
</html>
Давай Apple, исправь ошибки...
Это на самом деле совсем просто. Теперь это правда, что асинхронный запрос на самом деле является довольно хорошим помощником. Но вы должны иметь в виду, что это просто помощник. Http - это просто протокол для работы в сети, поэтому он НЕ ДОЛЖЕН взаимодействовать с пользователем. Другими словами, оба случая на самом деле одно и то же.
Если вы не хотите использовать помощника asynch, то я предлагаю вам показать диалоговое окно входа в систему и повторять ваш запрос, пока пользователь не нажмет "Отмена".
[редактировать]
просто для информации, лично я предпочитаю локон. Работает как шарм почти везде;)
Я столкнулся с проблемой, не получая 401 код несанкционированной ошибки (получал нулевой ответ и метод didReceiveResponse не вызывался) вместо получения -999 отмененной ошибки. Ошибка, которую я сделал в своем коде: В didReceiveChallenge: метод делегата,
if (challenge.previousFailureCount == 0)
{
//handle certificate trust
completionHandler (NSURLSessionAuthChallengeUseCredential, newCredential);
}
else
{
completionHandler (NSURLSessionAuthChallengeCancelAuthenticationChallenge, nil);
}
NSURLSessionAuthChallengeCancelAuthenticationChallenge приводил к ошибке -999, и ответ 401 не был получен. Вместо этого, когда я использовал завершение Handler (NSURLSessionAuthChallengePerformDefaultHandling, ноль); Я получил 401 ответ в didReceiveResponse: метод делегата, как и ожидалось.
Примечание из документации iOS https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/URLLoadingSystem/NSURLSessionConcepts/NSURLSessionConcepts.html Если мы отменим urlsession, то он будет сообщен как отмененный, но не как ошибка 401 в ответ.
Note: NSURLSession does not report server errors through the error parameter. The only errors your delegate receives through the error parameter are client-side errors, such as being unable to resolve the hostname or connect to the host. The error codes are described in URL Loading System Error Codes.
Server-side errors are reported through the HTTP status code in the NSHTTPURLResponse object. For more information, read the documentation for the NSHTTPURLResponse and NSURLResponse classes.