| Summary: | Third party cookie not working even when ITP is OFF | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Spambit <sarkar.sambit> |
| Component: | Frames | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | avik.pal, bfulgham, katherine_cheney, webkit-bug-importer, wilander |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
|
Description
Spambit
2020-09-30 11:52:05 PDT
(In reply to Spambit from comment #0) > I am on WKWebView in iOS14. I have ability to disable ITP in app settings as > I changed the info.plist with NSCrossWebsiteTrackingUsageDescription. I have > first-party context to http://127.0.0.1 and third-party context to > https://mydomain.com. So, I load a https domain in iframe from http > top-level-domain. > > I host a webapp inside iphone in gcdserver and load that web app from > http://127.0.0.1 domain. And then in that loaded app I load another web app > in iframe from a remotely hosted website - say https://mydomain.com. So, my > first-party context is 127.0.0.1 and my third-party context is mydomain.com. > The important thing is I load first-party domain 127.0.0.1 through native > URLSession as you see I use proxy to load the webapp. Also, I can intercept > xhr calls from locally hosted web app and serve response from iOS-native > even if xhr is made to absolute url of different domain. When first-party > context (locally hosted webapp at 127.0.0.1) makes an xhr request to > mydomain.com, native code intercepts the xhr and sets response cookies in > WKWebView cookieStore under mydomain.com before sending response to > WKWebView xhr. Now with ITP off, I expect the iframe.src=mydomain.com should > attach the cookie I received in first-party context through xhr and was > forcefully set to wkwebview store through native code. I think I am missing > something. Why iframe.src is not attaching cookies that I already forcefully > set in WKWebView cookiestore with iOS networking source code? Hi! Has this worked before the changes to WKWebView in iOS 14? This is our recent development. Did not check in iOS13. I am not sure what I am missing. If ITP is off, should all these not work? (In reply to Spambit from comment #2) > This is our recent development. Did not check in iOS13. I am not sure what I > am missing. If ITP is off, should all these not work? There’s an underlying cookie policy that might be at play here. It only allows cookies to be used for sites visited. This has always been the default cookie policy. Visited technically means “has previously been first party website and set at least one cookie as such.” Try that. Well, I guess I cannot instruct or let user visit third-party domain when our default domain is 127.0.0.1. Basically I must load a locally hosted webapp at first-launch. And then I need to load another web app from a different domain in iframe. I think embedding a webapp in an iframe from another is common. The web-app in 127.0.0.1 handles authenticating the user, and the application hosted in the iframe can trust that the user is signed in. This strategy does not work with WKWebView then. My whole question is why default cookie policy has to be in play even when ITP is off. At-least this does not happen with desktop safari 14.0. (In reply to Spambit from comment #4) > Well, I guess I cannot instruct or let user visit third-party domain when > our default domain is 127.0.0.1. Basically I must load a locally hosted > webapp at first-launch. And then I need to load another web app from a > different domain in iframe. I think embedding a webapp in an iframe from > another is common. The web-app in 127.0.0.1 handles authenticating the user, > and the application hosted in the iframe can trust that the user is signed > in. This strategy does not work with WKWebView then. My whole question is > why default cookie policy has to be in play even when ITP is off. At-least > this does not happen with desktop safari 14.0. It is true that the “Prevent cross-site tracking” setting in Safari controls both ITP and the underlying cookie policy. For WKWebView, the thing that has changed in iOS (in this regard) is that ITP is on by default and that the user can turn it off. There has never been a user setting for the underlying cookie policy in WKWebView. I think it would be good to change the title of this bug to an enhancement request that the web tracking setting for WKWebView should also control the cookie policy. I’m not saying everyone thinks that’s an enhancement but it seems that’s your perspective. |