Bug 140205 - WKWebView does not provide a way to set cookie accept policy
Summary: WKWebView does not provide a way to set cookie accept policy
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: iPhone / iPad All
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2015-01-07 14:05 PST by Eugene But
Modified: 2019-02-13 18:08 PST (History)
19 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eugene But 2015-01-07 14:05:45 PST
Summary:
With UIWebView, it’s possible to set the the cookie accept policy using -[NSHTTPCookieStorage setCookieAcceptPolicy:]. WKWebView does not appear to interoperate with NSHTTPCookieStorage. This makes it impossible to let users decide if they want to accept cookies or not.

Steps to Reproduce:
N/A, but for example:
- Create a trivial WKWebView app
- set [[NSHTTPCookieStorage sharedCookieStorage] setCookieAcceptPolicy:NSHTTPCookieAcceptPolicyNever]
- Browse around and see that cookies are still accepted

Expected Results:
Either NSHTTPCookieStorage working as expected (as it did with UIWebView), or WK* APIs for setting the cookie accept policy


Exposing -[WKProcessPool _setCookieAcceptPolicy:] as a public API will be perfect solution:
https://bugs.webkit.org/show_bug.cgi?id=130251
Comment 1 Eugene But 2015-01-07 16:06:28 PST
Radar ID: 19145620
Comment 2 Stuart Morgan 2015-06-15 15:18:17 PDT
This is now rdar://21391448 per devrel request.
Comment 3 Brady Eidson 2016-06-17 22:19:07 PDT
Have a patch that does this, but I'm not quite done with it, as I should make it handle the request in https://bugs.webkit.org/show_bug.cgi?id=140205 as well.
Comment 4 Brady Eidson 2016-06-17 22:19:49 PDT
(In reply to comment #3)
> Have a patch that does this, but I'm not quite done with it, as I should
> make it handle the request in https://bugs.webkit.org/show_bug.cgi?id=140205
> as well.

That comment was meant for Have a patch that does this, but I'm not quite done with it, as I should make it handle the request in https://bugs.webkit.org/show_bug.cgi?id=140191
Comment 5 Brady Eidson 2016-06-17 22:20:02 PDT
And that comment was not meant to have another copy of the comment in it.
Comment 6 Mike West 2018-09-20 14:28:29 PDT
CCing some folks.

Chrome on iOS has migrated to WKWebView, and in doing so has lost the ability to let users block third-party cookies. It would be lovely if WKWebView could provide us with that mechanism, perhaps in the way Eugene suggested in the initial comment.

Would y'all mind helping us get this request triaged?

Thanks!
Comment 7 Stefan Arentz 2018-09-20 15:48:58 PDT
Speaking for Firefox, we second this request.
Comment 8 Maciej Stachowiak 2018-09-24 14:27:18 PDT
Apple's WebKit team is discussing whether we can prioritize this higher.
Comment 9 David Kilzer (:ddkilzer) 2018-10-01 16:18:55 PDT
<rdar://problem/21391448>
Comment 10 anuja.sharma 2018-10-23 06:59:20 PDT
Hi Apple Team,

Our users are not able to access any third party applications in chrome on iOS because of default behavior for third party cookies got changed.
I would like to know when this issue will get resolved and since when the default behavior of third party cookies becomes blocked on iOS?
Comment 11 Eric Yen 2018-10-23 17:40:21 PDT
Hi team,
As mentioned by in c#10, could you share with us when did the Webkit start to block third party cookies as default behavior? 
Thanks.
Comment 12 John Wilander 2018-10-23 17:50:06 PDT
(In reply to Eric Yen from comment #11)
> Hi team,
> As mentioned by in c#10, could you share with us when did the Webkit start
> to block third party cookies as default behavior? 
> Thanks.

The default policy in WebKit on Cocoa platforms has been to block cookies from third-parties without pre-existing cookies since 2003. I’m not aware of any other default setting in WebViews.
Comment 13 Niklas Merz 2018-11-19 08:49:03 PST
For hybrid apps which rely solely on a webview (Cordova etc.) this can be a huge problem, because every request made to remote servers is a cross-origin request by design.

The default policy basically blocks those kind of apps from using cookie-based authentication at all.
Comment 14 John Wilander 2018-11-19 09:02:51 PST
(In reply to Niklas Merz from comment #13)
> For hybrid apps which rely solely on a webview (Cordova etc.) this can be a
> huge problem, because every request made to remote servers is a cross-origin
> request by design.

I what way are they cross-origin by design? What is the top frame origin? Do these requests differ from regular cross-origin ones? Who made the decision to make all these requests cross-origin by design? Thanks!

> The default policy basically blocks those kind of apps from using
> cookie-based authentication at all.
Comment 15 Niklas Merz 2018-11-19 09:45:08 PST
(In reply to John Wilander from comment #14)
> (In reply to Niklas Merz from comment #13)
> > For hybrid apps which rely solely on a webview (Cordova etc.) this can be a
> > huge problem, because every request made to remote servers is a cross-origin
> > request by design.
> 
> I what way are they cross-origin by design? What is the top frame origin? Do
> these requests differ from regular cross-origin ones?

I am starting to use the WKWebview plugin for Cordova made by the Ionic. 
(https://github.com/ionic-team/cordova-plugin-ionic-webview)

Because CORS does not work from files served via the file:// protocol this plugin is using a local webserver. These the requests are from the origin http://localhost:8080. Calling any origin within the Cordova app is now a cross-origin request. Because of this, authentication with cookies is not possible. Cookies just get ignored.

> Who made the decision
> to make all these requests cross-origin by design? Thanks!

The authors of the plugin made the decission because the file:// protocol is not usable in Cordova like it used to be with UIWebView. Ionic and others tried many different approaches and the local webserver was the best solution. WebKit serves local files with the origin header of "null" which does not allow any CORS requests.

Thanks for the quick response!
Comment 16 Niklas Merz 2018-11-20 00:39:07 PST
Aside from hybrid apps (Cordova etc.) this is a serious problem for pages with CORS requests and cookie authetication, if they are loaded in a webview or Browsers like Firefox or Chrome.

The default policy does not allow cookies for cross origin requests, too. Because of that we need a public API to change the policy.

Steps to reproduce the cross origin cookie behavior:
- Create a trivial WKWebView app
- WkWebView opens page on domain A
- Page on domain A sends request to domain B
- Domain A recieves cookie from Domain B via "Set-Cookie" header.
- Cookie does not show up in developer tools or "document.cookie"
- Domain A sends second request to domain B which requires cookie
- Domain B returns unauthorized response because request header contains no cookies

The default policy is great for blocking unwanted tracking cookies but breaks apps or webpages which need to send request to user-configured origins for authentication.
Comment 17 Lorenzo Boaro 2018-12-13 08:35:26 PST
Hi all! Any workaround so far?

Thanks,
Lorenzo
Comment 18 Lorenzo Boaro 2018-12-13 08:37:22 PST
(In reply to Niklas Merz from comment #16)
> Aside from hybrid apps (Cordova etc.) this is a serious problem for pages
> with CORS requests and cookie authetication, if they are loaded in a webview
> or Browsers like Firefox or Chrome.
> 
> The default policy does not allow cookies for cross origin requests, too.
> Because of that we need a public API to change the policy.
> 
> Steps to reproduce the cross origin cookie behavior:
> - Create a trivial WKWebView app
> - WkWebView opens page on domain A
> - Page on domain A sends request to domain B
> - Domain A recieves cookie from Domain B via "Set-Cookie" header.
> - Cookie does not show up in developer tools or "document.cookie"
> - Domain A sends second request to domain B which requires cookie
> - Domain B returns unauthorized response because request header contains no
> cookies
> 
> The default policy is great for blocking unwanted tracking cookies but
> breaks apps or webpages which need to send request to user-configured
> origins for authentication.

Before iOS 12 I was able to fix this following this approach:
https://medium.com/@flexaddicted/how-to-set-wkwebview-cookie-accept-policy-d8a2d3b77420

Now, I cannot do it anymore and for our goals is a big problem.