Невозможно повторно проверить подлинность с помощью других NSURLCredentials (используются старые удаленные)

Ответ 1

К сожалению, похоже, что решение этой проблемы не существует.

Вы можете использовать NSURLCredentialPersistenceNone или # трюк, или вы можете определить метод делегирования connectionShouldUseCredentialStorage для возврата NO. Если вы делаете это каждый раз, и ваше приложение никогда не сохраняет учетные данные для сеанса, это заставит проблему возникать при каждом запросе.

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

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

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

Как только вы храните учетные данные один раз для сеанса, они становятся кэшированными для всего сеанса TLS. Это приводит к необходимости ждать около 10 минут, пока этот сеанс не исчезнет.

Подробнее об этой проблеме вы можете узнать по адресу: http://developer.apple.com/library/ios/qa/qa1727/_index.html

В этом документе упоминается ограниченная работа, связанная с добавлением '.' до конца имени сервера. Однако я не смог получить эту работу.

Кроме того, это решения, о которых я могу думать:

1) Всегда используйте метод NSURLCredentialPersistenceNone и connectionShouldUseCredentialStorage, который должен генерировать 401s. Добавьте основной запрос проверки подлинности в запрос. Это должно предотвратить дополнительные 401, а также в обход хранилища учетных данных. Код для добавления этого авторизации выглядит примерно так:

    NSString *s ;
    NSString *authStr ;
    s = [NSString stringWithFormat:@"%@:%@",user,password] ;
    s = [YourBase64Encoder base64EncodingForData:[NSData dataWithBytes:[s UTF8String] length:strlen([s UTF8String])]];
    authStr = [NSString stringWithFormat:@"Basic %@",s] ;        
    [request setValue:authStr forHTTPHeaderField:@"Authorization"] ;

Я не знаю, как это будет реализовано для других методов проверки подлинности, но я предполагаю, что это возможно.

2) Сообщите пользователю о проблеме и попросите перезапустить приложение

3) Внедрите свой собственный низкоуровневый сокет на основе механизма поиска HTTP, который полностью обходит CFNetwork. Удачи вам в этом: > )

Ответ 2

Я просто столкнулся с этой проблемой с AFNetworking. Я работаю с бэкэнд, который требует, чтобы авторизация была передана в заголовке. Однако, когда пользователь выходит из приложения и пытается войти в систему (даже с разными кредитами), я получал сообщение об ошибке с сервера. Мое решение состояло в том, чтобы очистить файлы cookie приложений, очистив authheader при выходе из системы.

- (void)clearAuthorizationHeader {
    [self.manager.requestSerializer clearAuthorizationHeader];
    NSHTTPCookieStorage *storage = [NSHTTPCookieStorage sharedHTTPCookieStorage];
    for (NSHTTPCookie *cookie in [storage cookies]) {
        [storage deleteCookie:cookie];
    }
}

Ответ 3

Я тоже столкнулся с этой проблемой. Очистка NSURLCredentialStorage, похоже, частично работает, но кажется, что я должен ждать несколько секунд после этого, чтобы она вступила в силу. Выполнение другого HTTP-запроса без ожидающих результатов при использовании старого заголовка авторизации.

Мне удалось исправить его, передав NSURLCredentialPersistenceNone при инициализации my NSURLCredential:

NSURLCredential* credentials = [[NSURLCredential alloc] initWithUser:username password:password persistence:NSURLCredentialPersistenceNone];

note: это вызовет 401 Проблемы при каждом запросе HTTP, который вы сделаете с помощью этого NSURLCredential. Однако это не проблема, если вы вернете несколько файлов cookie, которые подтверждают вашу аутентификацию.

Ответ 4

Для чего это стоит, у меня такая же проблема.

Я думаю, что это вопрос времени. При использовании симулятора, если я жду 5-10 секунд, прежде чем пытаться войти в систему, логин завершится неудачно, как ожидалось. Кроме того, когда я использую реальный телефон, я редко могу возникнуть проблема, которая может быть функцией медленного движения телефона или может быть ошибкой в ​​симуляторе.

Ответ 5

Я знаю, что это старая тема. Однако единственное, что работает для меня, это использовать разные URL-адреса для разных сертификатов.

Он работал в моем приложении, так как у меня есть только два сертификата (один общий в ресурсах приложений и один пользовательский, загруженный из Интернета после процесса проверки пользователя). В моем случае нет файлов cookie и никаких учетных данных для очистки, поэтому ни одно из решений, которые я нашел при работе с stackoverflow, не работал.

Ответ 6

Я столкнулся с той же проблемой, теперь она работает.

Используя NSURLConnection, эту проблему можно легко устранить, добавив случайное число в конец URL-адреса:

Итак, найдите свой URLRequest и добавьте случайное число в URLRequest

NSInteger randomNumber = arc4random() % 999;
NSString *requestURL = [NSString stringWithFormat:@"%@?cache=%ld",yourURL,(long)randomNumber];

NSURL *URLRequest = [NSURL URLWithString:requestURL];

И убедитесь, что у вас есть случайное число в конце всех URL-адресов, которые вы вызываете.