Bug 188691 – REGRESSION (iOS 12): WKWebView cookies are empty in responseHeaders

• Status: NEW
• Component: WebKit2

[Raghavendra]

in IOS11 cookies can be read in decidePolicyForNavigationResponse as specified below.

- (void)webView:(WKWebView *)webView decidePolicyForNavigationResponse:(WKNavigationResponse *)navigationResponse decisionHandler:(void (^)(WKNavigationResponsePolicy))decisionHandler
{
 
NSDictionary *allFields = [(NSHTTPURLResponse*)response allHeaderFields];
NSArray *cookies = [NSHTTPCookie cookiesWithResponseHeaderFields:allFields forURL:[NSURL URLWithString:@""]];
//in iOS11 all cookies array contain all cookies
//in IOS12 beta, cookies are empty.

}

Since WkWebView default cookie APIs are still not providing correct cookie information, it is very important to rely cookie information from WkWebView Delegate Callbacks.
In iOS 12 Beta 8, we are seeing the Cookies are empty. 
To confirm again, Cookie information can be read in iOS11.2.x+ WkWebView.

[Radar WebKit Bug Importer]

<rdar://problem/43445256>

[Chris Dumez]

Yes, this was an intentional behavior change.

[John Polston]

Chris, is this intentional just for this build (Beta 8) or is this permanent and if so, is there a documented work-around or alternate method?

[Geoffrey Garen]

> Since WkWebView default cookie APIs are still not providing correct cookie
> information

Can you clarify this problem?

[Raghavendra]

WKHTTPCookieStore has below API to fetch cookies.
- (void)getAllCookies:(void (^)(NSArray<NSHTTPCookie *> *))completionHandler;

But the API does not work consistently. Sometimes it gets the cookies and sometimes it provides the old cookies even though new Cookies or updated cookies are available.
This API has not worked in iOS11 too and it's inconsistent behavior is continues to be there in iOS12 beta too.


What is the reason for not allowing apps to read cookies from headers? Each application is different, framework/platform should be rich to provide the required details through appropriate APIs. By fencing/curtailing capabilities do not add any value to users through development eco system.

[Sihui Liu]

(In reply to Raghavendra from comment #5)
> WKHTTPCookieStore has below API to fetch cookies.
> - (void)getAllCookies:(void (^)(NSArray<NSHTTPCookie *> *))completionHandler;
> 
> But the API does not work consistently. Sometimes it gets the cookies and
> sometimes it provides the old cookies even though new Cookies or updated
> cookies are available.
> This API has not worked in iOS11 too and it's inconsistent behavior is
> continues to be there in iOS12 beta too.
> 
> 
> What is the reason for not allowing apps to read cookies from headers? Each
> application is different, framework/platform should be rich to provide the
> required details through appropriate APIs. By fencing/curtailing
> capabilities do not add any value to users through development eco system.

Could you provide a test case where getAllCookies of WKHTTPCookieStore returns wrong cookies?

[bchenindeed]

(In reply to John Polston from comment #3)
> Chris, is this intentional just for this build (Beta 8) or is this permanent
> and if so, is there a documented work-around or alternate method?

Yes.  Would like an update on this as well.  I'm guessing this might be a fairly impactful decision for a number of developers.

[Sihui Liu]

HTTP headers in response are filtered for security. https://bugs.webkit.org/show_bug.cgi?id=184310

The intended way to retrieve cookies now is via WKHTTPCookieStore API. For cases it doesn't work as expected, please file a bug so we could improve it.

[bchenindeed]

Done: https://bugs.webkit.org/show_bug.cgi?id=188995

[Lorenzo Boaro]

This change has a deep impact.

Currently WKWebView does not offer an API to deal with third part cookies as per https://bugs.webkit.org/show_bug.cgi?id=140205.

WKHTTPCookieStore does not have an API in order to deal with this scenario.

Any workaround in the short term?

Thanks,
Lorenzo