Использование дайджест-аутентификации HTTP на iPhone

Во-первых, нужно забыть о сеансах HTTP, поскольку они не взаимодействуют с активными входами в систему с дайджест-аутентификацией (есть своего рода возможность информации о сеансе, но она другая).

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

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

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

Если у вас есть один и тот же одноразовый номер, используемый в каждом запросе, тогда пользовательский агент будет продолжать использовать его вместе с «ha1» от пользователя/пароля для запроса последующих ресурсов. Это делается упреждающе, поэтому вызов никогда не происходит.

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

Следовательно, если вы получаете запрос от пользовательского агента с недопустимым заголовком авторизации, но причина его недействительности заключается в том, что одноразовый номер неправильный (используется просроченный), то в запросе включите «stale=true» (по умолчанию ложный). Это информирует пользовательский агент о том, что ваша причина отклонения заключается в том, что одноразовый номер устарел (конечно, другая информация также может быть неправильной, но это не имеет значения, поскольку вы не собираетесь позволять ей воспроизводиться в любом случае).

При получении такого stale=true пользовательский агент будет знать, что он не авторизован, но вместо повторного запроса пользователя (или создания исключения, если это компонент без пользовательского интерфейса) повторит старые критерии с новым одноразовым номером.

Я не могу сказать, влияет ли что-то из этого на вас, но то, как определяются и сигнализируются nonces и staleness, — это, безусловно, первое, на что я бы обратил внимание.

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

Причина проблемы на стороне iPhone. Сервер должен ответить кодом 401, если iPhone не отправляет учетные данные в заголовке HTTP-запроса. И на самом деле это не так, хотя это легко могло бы быть, если учетные данные хранятся в хранилище учетных данных.

Это странное поведение сильно сказалось на скорости работы приложения, так как каждый запрос вызывал два обращения к серверу вместо одного (первый со статусом 401, второй со статусом 200).

Я решил это, вручную установив учетные данные в заголовке HTTP-запроса:

NSString* credentials = [NSString stringWithFormat: @"%@:%@", usr, pwd];
const char* credentialsChars = [credentials cStringUsingEncoding: NSUTF8StringEncoding];
credentials = [CommunicationUtil stringBase64WithData: (const UInt8*) credentialsChars length: strlen(credentialsChars)];
NSString* authorizationHeader = [NSString stringWithFormat: @"Basic %@", credentials];

NSMutableURLRequest* request =
    [[NSMutableURLRequest alloc] initWithURL: url 
        cachePolicy: NSURLRequestReloadIgnoringLocalCacheData
        timeoutInterval: 15];

    [request setValue: authorizationHeader forHTTPHeaderField: @"Authorization"];

Теперь мое приложение работает очень плавно и очень отзывчиво.

Решение будет выглядеть несколько иначе для дайджест-аутентификации. Но вы получите идею.