[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

Tudor Dumitriu <tudor.dumitriu at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tudor.dumitriu at gmail.com

--- Comment #40 from Tudor Dumitriu <tudor.dumitriu at gmail.com> ---
Hello there
Need to say that lots of us share Mad's frustration in regards to this issue, and even if there are workarounds they are time consuming and hard to implement.
Here is our situation, we have a cordova application packed and working perfectly on ios. 
The app is upgraded to latest cordova platform, hence running under app://localhost and is connecting to 2 different APIS, one https://db.domain.com:1234 (that is used for authentication and data) and https://db.domain.com:4567 (for other functionality). 
The problem is that even if the first call to https://db.domain.com:1234/_session returns correctly with the header 
Set-Cookie: AuthSession=yyyy; Version=1; Expires=Sat, 13-Mar-2021 11:23:42 GMT; Max-Age=2600000; Secure; Domain=domain.com; Path=/; HttpOnly; SameSite=None
The next call to https://db.domain.com:1234/ doesn't have the cookie anymore and any subsequent calls fail (and ofc any calls to  https://db.domain.com:4567 as well)
So, just to get things a little clearer the problem is the fact we are running the app under app://localhost (top frame registrable domain (eTLD+1)) but consuming an API from https://db.domain.com hence (which is not matching the same site rule).
Since we cannot control that the only option would be to list these accepted domains in a setting.
So the questions is, is there any chance of getting this fixed by the Apple team, or is actually someone working on it, are any estimations on when will this be shipped?
Or should we just try to find alternatives (again, quite hard to implement)
Thanks

-- 
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/20210211/561cf516/attachment.htm>