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&amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage11(MessageRpc&amp; 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.
Другие вопросы по тегам