Подтвердить что ты не робот

IOS: Как я могу получить HTTP 401 вместо -1012 NSURLErrorUserCancelledAuthentication

У меня проблема, подобная той, что описана в приведенной ниже ссылке.

NSHTTPURLResponse statusCode возвращает ноль, если он должен быть 401

Я использую [NSURLConnection sendSynchronousRequest:returningResponse:error:] для получения данных с сервера.

Когда NSURLConnection получает HTTP-код 401, он не возвращает ничего, кроме объекта ошибки с кодом -1012 из NSURLErrorDomain. -1012 соответствует NSURLErrorUserCancelledAuthentication. Поскольку я должен разбирать HTTP-заголовок, мне нужно получить исходную ошибку, а не то, что из нее было сделано NSURLConnection.

Есть ли способ получить исходный 401 http-пакет?

4b9b3361

Ответ 1

Да. Прекратите использование синхронного API. Если вы используете асинхронный API на основе делегирования, тогда у вас есть намного больше контроля над соединением. С помощью этого API, за исключением случаев, когда ошибка встречается до получения заголовка HTTP, вы всегда будете получать -connection:didReceiveResponse:, что дает вам доступ к полям заголовка HTTP (инкапсулированные в объект NSURLResponse). Вы также можете реализовать аутентификацию, используя соответствующие методы делегата, если вы так склонны.

Ответ 2

Обход проблемы:

[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;
   }

Не лучшее решение, но оно работает!

Ответ 3

Я удивлен "рекомендуемым" ответом на эту тему.

Хорошо, я уверен, что лучше использовать методы асинхронной версии, но это все еще не объясняет, почему функция sendSynchronousRequest позволяет вам передать переменную, чтобы вернуть код ответа, но в некоторых случаях это просто возвращает nil.

Прошло 4 года с момента появления этой проблемы, я использую XCode 6.2 с iOS 8.2, и эта древняя ошибка все еще присутствует.

Мои веб-службы сознательно возвращают ошибку 401, когда пользовательское имя пользователя и пароль неверны.

Когда мое приложение iPhone вызывает эту службу (с неправильными учетными данными)...

NSHTTPURLResponse *response = nil;
NSData *data = [ NSURLConnection sendSynchronousRequest:request returningResponse:&response error:&error ];

.. response возвращается как nil (поэтому я не могу проверить HTTP-ответ 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, исправьте свои ошибки...

Ответ 4

На самом деле это просто невозможно. Теперь верно, что асинхронный запрос на самом деле довольно хороший помощник. Но вы должны иметь в виду, что это всего лишь помощник. Http - это всего лишь протокол для сетей, и поэтому он НЕ ДОЛЖЕН взаимодействовать с пользователем. Другими словами, оба случая на самом деле одно и то же.

Если вы не хотите использовать помощник asynch, я предлагаю вам показать пользователю диалоговое окно входа в систему и повторить запрос до тех пор, пока пользователь не отменит отмену.

[править]

просто для информации, лично я предпочитаю завиток. Работает как шарм почти везде;)

Ответ 5

Я столкнулся с проблемой, не получавшей 401 Несанкционированный код ошибки (получал нулевой ответ, также метод didReceiveResponse не вызывался), вместо этого получал -999 отмененную ошибку. Ошибка, которую я выполнял в своем коде: В didReceiveChallenge: метод делегирования,

if (challenge.previousFailureCount == 0)
{
    //handle certificate trust
    completionHandler (NSURLSessionAuthChallengeUseCredential, newCredential);
}
else
{
    completionHandler (NSURLSessionAuthChallengeCancelAuthenticationChallenge, nil);
}

В NSURLSessionAuthChallengeCancelAuthenticationChallenge возникла ошибка -999, и не было получено ответа 401. Вместо этого, когда я использовал completeHandler (NSURLSessionAuthChallengePerformDefaultHandling, nil); Я получил ответ 401 в методе didReceiveResponse: delegate как ожидалось.

Примечание из документации iOS https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/URLLoadingSystem/NSURLSessionConcepts/NSURLSessionConcepts.html. Если мы отменим URL-адрес, то он будет сообщаться как отмененный, но не как ошибка 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.