NSURLSession с пользовательской аутентификацией?

Проблемы аутентификации инициируются заголовком WWW-Authenticate в ответе 40x.

Из документации:

Системные классы загрузки URL не вызывают своих делегатов для обработки запросов запросов, если ответ сервера не содержит заголовок WWW-Authenticate. Для других типов проверки подлинности, таких как проверка подлинности прокси и проверка доверия TLS, этот заголовок не требуется.

К сожалению, вышеупомянутая прокси-аутентификация не применяется в вашем сценарии обратного прокси / ускорителя.

На ум приходит пара возможностей.

1. Если вы используете представление NSURLSession делегатом, вы можете обнаружить перенаправление на страницу сбоя аутентификации с помощью NSURLSessionTaskDelegate метода willPerformHTTPRedirection.

   Вероятно, вы также можете обнаружить перенаправление, проверив currentRequest.URL задачи и увидев, произошло ли перенаправление и там. Как говорится в документации, currentRequest «обычно совпадает с исходным запросом (originalRequest), за исключением случаев, когда сервер ответил на первоначальный запрос перенаправлением на другой URL-адрес».

2. Предполагая, что служба RESTful обычно не возвращает HTML, вы можете посмотреть NSURLResponse, подтвердить, что это действительно подкласс NSHTTPURLResponse, а затем посмотреть allHeaderFields, чтобы убедиться, что text/html появляется в Content-Type ответа. Это, очевидно, работает только в том случае, если страница аутентификации возвращает Content-Type, который включает text/html, а остальные ваши ответы - нет (например, они application/json или что-то в этом роде).

   Во всяком случае, это может выглядеть так:

   NSString *contentType = [self headerValueForKey:@"Content-Type" response:response];
   
   if ([contentType rangeOfString:@"text/html"].location != NSNotFound) {
       // handle it here
   }
   

   Где headerValueForKey может быть определено следующим образом:

   - (NSString *)headerValueForKey:(NSString *)searchKey response:(NSURLResponse *)response
   {
       if (![response isKindOfClass:[NSHTTPURLResponse class]])
           return nil;
   
       NSDictionary *headers = [(NSHTTPURLResponse *) response allHeaderFields];
   
       for (NSString *key in headers) {
           if ([searchKey caseInsensitiveCompare:key] == NSOrderedSame) {
               return headers[key];
           }
       };
   
       return nil;
   }
   

3. В худшем случае вы можете обнаружить ответ HTML и проанализировать его, используя что-то вроде HPPLE, и программно обнаружить ответ HTML аутентификации.

   См. Статью Вендерлиха Как разбирать HTML на iOS.

Честно говоря, я бы предпочел видеть ответ REST, чтобы сообщить об ошибке аутентификации с ответом REST (или правильным запросом на сбой аутентификации или ответом, отличным от 200), а не перенаправлением на страницу HTML. Если у вас есть возможность изменить ответ сервера, это будет мое личное предпочтение.

Вы пробовали просто установить имя пользователя и пароль для заголовка авторизации NSMutableURLRequest как такового.

NSString *authorizationString = [[[NSString stringWithFormat:@"%@:%@",user, password] dataUsingEncoding:NSUTF8StringEncoding] base64Encoding]; 

[yourRequest setValue:[NSString stringWithFormat:@"Basic %@", authorizationString] forHTTPHeaderField:@"Authorization"];

Это должно сработать.

Вы можете попробовать использовать библиотеку парсера HTML (например, https://github.com/nolanw/HTMLReader).

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

Я не знаю эту библиотеку, но думаю, вы можете использовать ее так:

HTMLDocument *document = [HTMLDocument documentWithString:responseObjectFromServer];
HTMLNode *node = [document firstNodeMatchingSelector:@"form.login"];
if(node) {
    // Perform second NSURLSession call with login data
}