概述
WKWebView Cookie Issue主要包括:
Cookie丢失问题
Cookie同步延迟问题
Cookie丢失问题
使用过WKWebView的都会遇到请求没有带上登录态,页面访问失败的情况。在UIWebView中发起的请求会自动带上存储于NSHTTPCookieStorage容器中的Cookie,因此,我们一般都会将登录态存储于NSHTTPCookieStorage中;而WKWebView发起的请求不会自动带上存储于NSHTTPCookieStorage容器中的Cookie,目前主流的解决方案是:
- loadRequest前,在request header中设置Cookie, 解决首个请求Cookie带不上的问题;
WKWebView *webView = [WKWebView new];
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http://y.qq.com"]];
[request setValue:@"skey=MgYzJipDFA" forHTTPHeaderField:@"Cookie"];
[webView loadRequest:request];
- 通过document.cookie设置Cookie解决后续页面Ajax、iframe等请求的Cookie问题;
WKUserContentController *userContentController = [WKUserContentController new];
WKUserScript *cookieScript = [[WKUserScript alloc] initWithSource: @"document.cookie = 'skey=MgYzJipDFA';" injectionTime:WKUserScriptInjectionTimeAtDocumentStart forMainFrameOnly:NO];
[userContentController addUserScript:cookieScript];
这种方案在遇到302请求的时候有点捉襟见衬,比如:
第一个请求
RequestA: www.a.com
,我们通过在request header里带上Cookie:skey=MgYzJipDFA
解决该请求的Cookie问题,接着RequestA重定向到RequestB:www.b.com
,这个时候RequestB就可能因为没有携带www.b.com域名的Cookie而失败。更棘手的是这里RequestB:www.b.com
和RequestA:www.a.com
其实是地址相同的同一个对象,也就是说RequestB会带上我们在RequestA header里设置的Cookie:skey=MgYzJipDFA,这样如果RequestA是重定向到第三方网站,就可能导致Cookie信息泄漏问题。当然,由于每一次页面跳转前都会调用回调函数:
- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler;
可以在该回调函数里拦截跳转请求,在request header中带上或擦除Cookie,确保Cookie字段信息和NSHTTPCookieStorage容器中的一致,并重新loadRequest。不过这种方法依然解决不了页面iframe跨域请求的Cookie问题,毕竟-[WKWebView loadRequest:]只适合加载mainFrame Request。
document.cookie不能垮域设置Cookie,因此,document.cookie添加Cookie的逻辑可以简单调整下:
通过-[WKUserScript addUserScript:]注入脚本A,A不再是执行document.cookie设置Cookie,而是在documentStart的时候,抛通知(webkit messageHandlers)给客户端,客户端收到通知后,从NSHTTPCookieStorage容器中取出window.location.href对应的Cookie,并执行document.cookie将Cookie注入。
Cookie同步问题
document.cookie或response set-Cookie设置的Cookie会先存储在WKWebView Cookie缓存(这里WKWebView Cookie缓存的说法可能不是很准确)中,然后再同步到NSHTTPCookieStorage容器中,而同步过程有1~2s左右的延迟(setCookie有1.5s左右的延迟,而document.cookie的延迟更高些,大概在2.0s左右)。通过document.cookie设置Cookie的时候,如果没有指定过期时间,则属于Session Cookie, WKWebView不会将Session Cookie同步到NSHTTPCookieStorage中,这点和UIWebView有点差异。WKWebView发起的请求会自动带上缓存中的Cookie而不会自动带上NSHTTPCookieStorage中的Cookie。
-
set-Cookie
- (void)webView:(WKWebView *)webView decidePolicyForNavigationResponse:(WKNavigationResponse *)navigationResponse decisionHandler:(void (^)(WKNavigationResponsePolicy))decisionHandler;
通过该回调函数可以获取部分response header set-Cookie字段,将Cookie信息同步到NSHTTPCookieStorage中;
-
document.cookie
可以在javascript层hook document.cookie set method,不过目前发现只有IOS 10系统上能hook成功;另一种做法是设置定时器,检查document.cookie是否有更新,如果有则抛通知给客户端,客户端将Cookie信息同步到NSHTTPCookieStorage中; -
WKProcessPool
通过让所有WKWebView共享同一个WKProcessPool实例,可以实现多个WKWebView之间共享Cookie数据,尤其是Session Cookie;
相对完美的方案
前面两个问题的讨论都是建立在WKWebView不支持NSURLProtocol的基础上,如果WKWbView支持NSURLProtocol:
- WKWebView请求将从Network Process转发到App Process, 最后由Loading System用NSURLConnection发起请求;
- NSURLConnection发起的请求会自动带上NSHTTPCookieStorage中的Cookie;
- NSURLConnection响应的set-Cookie字段会自动存储到NSHTTPCookieStorage中;
综合上面3点,WKWebView Cookie Issue就只剩下document.cookie的同步问题;
笔者对webkit2没有特别深入的了解,如有表述错误欢迎指正!
网友评论