WKWebView неправильно обрабатывает заголовок "Set-Cookie"
Я использую WKWebView в своем проекте для реализации веб-интерфейса авторизации. Я использую [NSHTTPCookieStorage sharedHTTPCookieStorage] для хранения файлов cookie сеанса пользователя всего приложения и аутентификации пользователя в случае перенаправления WKWebView на наши внутренние страницы.
Проблема в том, что в этом случае WKWebView игнорирует заголовок "Set-Cookie" для других доменов. Например:
Первоначальный запрос на настройку процесса аутентификации:
GET /api2/providers/misfit/start/ HTTP/1.1
Host: api.welltory.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate
Connection: keep-alive
Proxy-Connection: keep-alive
Cookie: csrftoken=haF3PX9l6VB9DrTJTNEQvsjsAiMZTYNC;sessionid=txo4fhez18vl6mvjuwlelph1uyn1pkau
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/601.6.17 (KHTML, like Gecko) Version/9.1.1 Safari/601.6.17
X-CSRFToken: haF3PX9l6VB9DrTJTNEQvsjsAiMZTYNC
Referer: https://api.welltory.com/api2/api/version/
Accept-Language: ru
Результатом этого запроса является перенаправление на страницу входа целевой службы, где у нас есть запрос, перечисленный ниже:
GET /auth/dialog/authorize?scope=public+birthday+email+tracking+session+sleeps&state=NdhVfDpcCTfjCkuEbgnoj0E4s8pnw6wv&client_id=ZkwJzk9QvaEkzL4M&response_type=code&redirect_uri=https%3A%2F%2Fapi.welltory.com%2Fapi2%2Fproviders%2Fmisfit%2Ffinish%2F%3Fredirect_state%3DNdhVfDpcCTfjCkuEbgnoj0E4s8pnw6wv HTTP/1.1
Host: api.misfitwearables.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
X-CSRFToken: haF3PX9l6VB9DrTJTNEQvsjsAiMZTYNC
Connection: keep-alive
Proxy-Connection: keep-alive
Cookie: csrftoken=haF3PX9l6VB9DrTJTNEQvsjsAiMZTYNC;sessionid=txo4fhez18vl6mvjuwlelph1uyn1pkau
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/601.6.17 (KHTML, like Gecko) Version/9.1.1 Safari/601.6.17
Accept-Language: ru
Referer: https://api.welltory.com/api2/api/version/
Accept-Encoding: gzip, deflate
HTTP/1.1 302 Moved Temporarily
Content-Type: text/html; charset=UTF-8
Date: Tue, 19 Jul 2016 11:15:01 GMT
Location: /auth/login
Set-Cookie: connect.sid=s%3AROcF81HPxNkajBr1z3s4MI8e.5nm4JigW3g6FnemCzM2SMYXF%2Bed0xxvcAjIwhwTe4ro; Path=/; HttpOnly
Vary: Accept
X-Powered-By: Express
Content-Length: 78
Connection: keep-alive
<p>Moved Temporarily. Redirecting to <a href="/auth/login">/auth/login</a></p>
Здесь мы видим заголовок Set-Cookie. И я ожидаю увидеть этот файл cookie в следующем перенаправленном запросе, сделанном самим api.misfitwearables.com. Но то, что я вижу здесь, следующее:
GET /auth/login HTTP/1.1
Host: api.misfitwearables.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Connection: keep-alive
Proxy-Connection: keep-alive
Cookie: csrftoken=haF3PX9l6VB9DrTJTNEQvsjsAiMZTYNC;sessionid=txo4fhez18vl6mvjuwlelph1uyn1pkau
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/601.6.17 (KHTML, like Gecko) Version/9.1.1 Safari/601.6.17
Accept-Language: ru
Referer: https://api.welltory.com/api2/api/version/
Accept-Encoding: gzip, deflate
Я прошел тот же тест с автономным Safari, и все поведение было, как я ожидал.
Я не понимаю, что может повлиять на WKWebView таким образом. Я буду признателен за любые предложения, как я мог бы исследовать это странное поведение.
UPD: Интересно отметить, что если первый запрос содержит заголовок Cookie, то Set-Cookie из всех последующих ответов не работает. Похоже, ошибка, и я понятия не имею, как это исправить.
UPD2: Как я заметил, просматривая другие запросы, Set-Cookie работал правильно. Но кажется, что HTTP-клиент думает, что 3xx перенаправляет последовательность как один запрос, каждый из которых может иметь те же заголовки HTTP, что и первый, не обращая внимания на домены конечного целевого URL.
Так что, если первый запрос имеет заголовок "X-CSRFToken: haF3PX9l6VB9DrTJTNEQvsjsAiMZTYNC", то второй и третий тоже имеют его. Та же логика применяется к Cookie.
И поскольку у большинства заголовков есть действительно веские причины для репликации из запроса в запрос во время выполнения последовательности перенаправления, заголовок Cookie не так очевиден. Я не нашел никаких прямых правил об этом поведении.
Кстати, в моем случае, когда первое перенаправление было сделано бэкендом, разработанным в моей команде, я попросил разработчика сервера избегать использования перенаправлений с нашего сервера таким образом и предоставил мне прямой URL-адрес целевого сервера для запуска процесса авторизации.