[Webkit-unassigned] [Bug 213510] iOS 14: ITP causes issues for hybrid (WKWebView) apps using cookies for authentication etc.

[bugzilla-daemon at webkit.org]

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

--- Comment #52 from Niklas Merz <niklasmerz at apache.org> ---
Some time has passed and I can share the sentiment that cookies are the main pain point of WKWebView. I have been watching a few Cordova issues where some people try to figure out solutions for cookie problems.

Aside from some weird behaviors of NSHTTPCookieStorage, I never really fully understood, there are no actual bugs right now AFAIK, but ITP brings some app devs in trouble. Probably many don't identify it right away as the cause of their issues. Maybe that's the reason we don't get many reports. What could help here would be a way to debug ITP in WKWebView, like a special indication for blocked tracking in Safari Web Inspector?

A handful of Cordova developers got directly in touch with me because of my bug reports and blog posts. With some of them I talked extensively about their use cases of CORS cookies and possible alternatives. The biggest use case is similar to mine: Their app connects to a backend that's either not in their control or does not support an authentication without cookies. Often it's just one or two domains I think.

Cordova/Capacitor apps are almost never a general web browser, but load web content from the app bundle. ITP does not really make sense in this context as WKWebView is just used to built a "native app with web technology". If Cordova apps browse web pages most of the time the InAppBrowser plugin is used which opens another WKWebView where ITP would make sense again. 

Is it unthinkable to have an option to disable for WKWebView instances? Maybe having ITP disabled when a WKWebView uses WKURLSchemeHandler to serve content from a custom scheme would be a good compromise. WKWebViews used for web browsing where ITP is good won't be using custom schemes but Cordova/Capacitor apps often do to serve their content.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210702/c9e69038/attachment-0001.htm>