I am working on WKWebView in iOS 14. I load a website from http://127.0.0.1 and then I load another domain in iframe inside that web app. I put NSCrossWebsiteTrackingUsageDescription in info.plist. So, I have ability to ON/OFF ITP. Looks like the requestStorageAccess does not work in WKWebView even with user gesture. Moreover, if ITP is off, inside iframe, requestStorageAccess() in WKWebView (iOS 14.0) does not gain access for first-party cookie storage. It neither throw any prompt to user like safari 14.0 does when ITP is ON. However, according to webkit blog prompting the user on requestStorageAccess() was removed. But, this is clear mismatch between WKWebView vs Safari. The hasStorageAccess() API works same in both platforms though. I think I am missing something. So, I guess my question is if I turn off ITP, should I not gain access to first-party cookie storage inside iframe in iOS14?
Hi! There are many things you bring up so let’s figure it out in small chunks. Let us assume that you have turned ITP off in WKWebView. Have you set at least one cookie for your third-party domain when it was first-party? If not, what happens when you do?
I made xhr to third-party domain from http:127.0.0.1 and received cookies in WKWebView. I saw those in xhr-response in web-inspector. But I noticed those cookies never reached third-party server in subsequent network calls from iframe or even another xhr from http://127.0.0.1. I saw same behaviour with ITP off. I read that WKWebView now blocks all third-party cookies. Does this mean it won't send cookies to different domain other than 127.0.0.1 even when ITP is off? My original question was on mismatch behaviour in desktop safari and WkWebView. That stays same. I saw everything I explained above works fine in desktop safari as it should be according to me even with storage apis. But, I could not make it working in iOS safari and WKWebView. Anyway, to answer your question, if I set third-party cookie in first-party context, it does not work either with ITP on/off. However, my third-party domain was never first-party at all. There had been only xhr calls to third-party domain.
<rdar://problem/70056820>
(In reply to Spambit from comment #2) > I made xhr to third-party domain from http:127.0.0.1 and received cookies in > WKWebView. I saw those in xhr-response in web-inspector. But I noticed those > cookies never reached third-party server in subsequent network calls from > iframe or even another xhr from http://127.0.0.1. I saw same behaviour with > ITP off. I read that WKWebView now blocks all third-party cookies. Does this > mean it won't send cookies to different domain other than 127.0.0.1 even > when ITP is off? My original question was on mismatch behaviour in desktop > safari and WkWebView. That stays same. I saw everything I explained above > works fine in desktop safari as it should be according to me even with > storage apis. But, I could not make it working in iOS safari and WKWebView. > Anyway, to answer your question, if I set third-party cookie in first-party > context, it does not work either with ITP on/off. However, my third-party > domain was never first-party at all. There had been only xhr calls to > third-party domain. My understanding is that you see a Set-Cookie header in the HTTP response to your XHR. But do you see that cookie being accepted? When cookies are blocked, they still show up on responses but don't get accepted. Cookies that have been accepted should show up in the Storage –> Cookies pane in Web Inspector. The mismatch you might be seeing here is that the "Prevent cross-site tracking" setting in Safari controls *both* ITP and the underlying cookie policy. However, there has never been a user setting to control the cookie policy in WKWebViews. The change in iOS 14 that we're talking about is that ITP is enabled by default and that users can turn it off. The underlying cookie policy has not changed. I suspect that what you're describing has never worked in WKWebView. The cookie policy says that a response to a third-party request can only set cookies if the third-party has set its initial cookie(s) as *first-party*. This used to be called "Accept cookies for sites I visit" in Safari's settings pre-ITP.