我在项目中使用WKWebView来实现基于Web的授权UI。我使用[NSHTTPCookieStorage sharedHTTPCookieStorage]来保留整个应用程序的用户会话cookie，并在WKWebView重定向到我们的后端页面时保持用户身份验证。
问题是看起来WKWebView忽略了＆＃34; Set-Cookie＆＃34;在这种情况下，其他域的标头。例如：
设置身份验证过程的初始请求：
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标头。我期望在api.misfitwearables.com本身的下一个重定向请求中看到这个cookie。但我在下面看到的是：
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的域。
因此，如果第一个请求有＆＃34; X-CSRFToken：haF3PX9l6VB9DrTJTNEQvsjsAiMZTYNC＆＃34;标题，第二个和第三个也有它。同样的逻辑应用于Cookie。
由于大多数标头都有很好的理由在重定向序列执行期间从请求复制到请求，因此Cookie标头不是那么明显。我没有找到关于这种行为的直接规则。
顺便说一句，在我的情况下，第一次重定向是由我的团队开发的后端进行的，我要求服务器开发人员避免以这种方式使用我们服务器的重定向，并为我提供目标服务器的直接URL来启动授权过程。