Не удается выполнить повторную аутентификацию с использованием разных учетных данных NSURLC (используются старые удаленные)

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

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

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

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

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

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

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

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

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

1) Всегда используйте обходной путь NSURLCredentialPersistenceNone и connectionShouldUseCredentialStorage, который должен генерировать ошибки 401. Добавьте заголовок базовой аутентификации в запрос самостоятельно. Это должно предотвратить дополнительные ошибки 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. Удачи в этом :>)

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

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

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

Я смог исправить это, передав NSURLCredentialPersistenceNone при инициализации моего NSURLCredential:

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

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

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

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

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

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

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

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

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

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

NSURL *URLRequest = [NSURL URLWithString:requestURL];

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