Решение, как реагировать на запрос аутентификации

Если NSURLRequest объект требует аутентификации, способ, которым проблема представлена собой к Вашему приложению, варьируется в зависимости от того, выполняется ли запрос NSURLSession объект, NSURLConnection объект, или NSURLDownload объект:

• Если запрос связан с NSURLSession объект, все запросы аутентификации передаются делегату, независимо от типа аутентификации.

• Если запрос связан с NSURLConnection или NSURLDownload объект, что делегат объекта получает a connection:canAuthenticateAgainstProtectionSpace: (или download:canAuthenticateAgainstProtectionSpace:) сообщение. Это позволяет делегату анализировать свойства сервера, включая его протокол и метод аутентификации, прежде, чем пытаться аутентифицировать против него. Если Ваш делегат не подготовлен аутентифицировать против пространства защиты сервера, можно возвратиться NO, и система пытается аутентифицировать с информацией от цепочки для ключей пользователя.

• Если делегат NSURLConnection или NSURLDownload объект не реализует connection:canAuthenticateAgainstProtectionSpace: (или download:canAuthenticateAgainstProtectionSpace:) метод и пространство защиты используют клиентскую аутентификацию сертификата или аутентификацию доверия сервера, система ведет себя, как будто Вы возвратились NO. Система ведет себя, как будто Вы возвратились YES для всех других типов аутентификации.

Затем, если Ваш делегат соглашается обработать аутентификацию и нет никаких допустимых доступных учетных данных, или как часть требуемого URL или в совместно используемом NSURLCredentialStorage, делегат получает одно из следующих сообщений:

• URLSession:didReceiveChallenge:completionHandler:

• URLSession:task:didReceiveChallenge:completionHandler:

• connection:didReceiveAuthenticationChallenge:

• download:didReceiveAuthenticationChallenge:

Для соединения для продолжения у делегата есть три опции:

• Обеспечьте учетные данные аутентификации.

• Попытка продолжаться без учетных данных.

• Отмените запрос аутентификации.

Помочь определить корректный план действий, NSURLAuthenticationChallenge экземпляр, переданный методу, содержит информацию о том, что инициировало запрос аутентификации, сколько попыток было предпринято для проблемы, любых ранее опробованных учетных данных, NSURLProtectionSpace это требует учетных данных и отправителя проблемы.

Если запрос аутентификации попытался аутентифицировать ранее и перестал работать (например, если пользователь изменил его или ее пароль на сервере), можно получить опробованные учетные данные путем вызова proposedCredential на запросе аутентификации. Делегат может тогда использовать эти учетные данные для заполнения диалогового окна, которое это представляет пользователю.

Вызов previousFailureCount на запросе аутентификации возвращает общее количество предыдущих попыток аутентификации, включая тех от различных протоколов аутентификации. Делегат может предоставить эту информацию пользователю, чтобы определить, перестали ли учетные данные, которые она предоставила ранее, работать, или ограничить максимальное количество попыток аутентификации.

Ответ на запрос аутентификации

Следующее является этими тремя способами, которыми можно ответить на connection:didReceiveAuthenticationChallenge: метод делегата.

-(void)connection:(NSURLConnection *)connection

        didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge

{

    if ([challenge previousFailureCount] == 0) {

        NSURLCredential *newCredential;

        newCredential = [NSURLCredential credentialWithUser:[self preferencesName]

                                                 password:[self preferencesPassword]

                                              persistence:NSURLCredentialPersistenceNone];

        [[challenge sender] useCredential:newCredential

               forAuthenticationChallenge:challenge];

    } else {

        [[challenge sender] cancelAuthenticationChallenge:challenge];

        // inform the user that the user name and password

        // in the preferences are incorrect

        [self showPreferencesCredentialsAreIncorrectPanel:self];

    }

}

Выполнение пользовательской проверки цепочки TLS

В семье NSURL APIs проверка цепочки TLS обрабатывается методом делегата аутентификации Вашего приложения, но вместо того, чтобы обеспечить учетные данные для аутентификации пользователя (или приложение) к серверу приложение вместо этого проверяет учетные данные, которые сервер обеспечивает во время квитирования TLS, затем говорит загрузочную систему URL, должно ли это принять или отклонить те учетные данные.

Если необходимо выполнить цепочечную проверку нестандартным способом (таким как принятие определенного самоподписанного сертификата для тестирования), приложение должно сделать следующее:

• Для NSURLSession, реализуйте любого URLSession:didReceiveChallenge:completionHandler: или URLSession:task:didReceiveChallenge:completionHandler: метод делегата. При реализации обоих метод сеансового уровня ответственен за обработку аутентификации.

• Для NSURLConnection и NSURLDownload, реализуйте connection:canAuthenticateAgainstProtectionSpace: или download:canAuthenticateAgainstProtectionSpace: метод и возврат YES если пространство защиты имеет тип аутентификации NSURLAuthenticationMethodServerTrust.

  Затем реализуйте connection:didReceiveAuthenticationChallenge: или download:didReceiveAuthenticationChallenge: метод для обработки аутентификации.

В Вашем методе делегата обработчика аутентификации необходимо проверить, чтобы видеть, имеет ли пространство защиты проблемы тип аутентификации NSURLAuthenticationMethodServerTrust, и если так, получите serverTrust информация от того пространства защиты.

Для дополнительных подробных данных и фрагментов кода (на основе NSURLConnection), считайте Переопределяющую Проверку Цепочки TLS Правильно.