ASWebAuthenticationSession cookie

The upgrade to iOS 14.5 fixed Great news! For example, this issue persists with a user with this user-agent: Mozilla/5.0 (iPhone; CPU iPhone OS 14_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1 Mobile/15E148 Safari/604.1. From the logs I can see that, with ASWebAuthenticationSession, cookies that are correctly set by our server in set-cookie header but are not sent by Safari in the following calls. I precise that we only use first-party cookies. I'm confused what the User-Agent string has to do with the issue persisting? Are you able to provide any more information about the non-working case? Have these users not updated to iOS 14.5 yet? Matt Eaton DTS Engineering, CoreOS meaton3@apple.com

Hello, Do you have some feedback regarding this fix? The upgrade to iOS 14.5 fixed the issue for some of our users but not for all of them. For example, this issue persists with a user with this user-agent: Mozilla/5.0 (iPhone; CPU iPhone OS 14_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1 Mobile/15E148 Safari/604.1. From the logs I can see that, with ASWebAuthenticationSession, cookies that are correctly set by our server in set-cookie header but are not sent by Safari in the following calls. I precise that we only use first-party cookies. This concerns a very small number of users but they are completely blocked with no other solution than to reset their iPhone or to buy a new one. Regards,

In case any one else has this issue, if you go to https://appstoreconnect.apple.com then it would work, https://itunesconnect.apple.com seem to redirect aswell but some sort of cookie/cache data breaks everything. I hope this helps!

I believe this is a security issue. I utilize a DNS honeypot and VPN to limit advertising cookies and unseen hooks by Amazon, Google, etc into my home in order to privatize my personal data and browsing history and this causes issues with updating my Apple, and other services. When I disable it, everything updates just fine. I then enable my security and feel secure once again

Resorved the problem after 1 month! Just use Safari browser(clear all cookies and cache) and make sure your account's location and IP are same country.

ADDENDUM: One thing that would clarify this problem, however not solve it, is the fact that a plain • myWebview.load(URLRequest) is using Mozilla/5.0 as the agent, which is confirmed by the server log. However • URLSession.shared.dataTask(with: URLRequest) { data, response, error in ... } uses a CFNetwork executionExtension as the agent, also confirmed by the server log. So if the executionExtension spins up its own URLSession that writes the cookies to the cookieStore, it could be that after the dataTask’s completion handler the session gets deallocated and hence the temporary session cookies get removed from the cookieStore right away. The question then is, how do you get a copy of those short-lived cookies before the extension closes, because even • myWebview.configuration.websiteDataStore.httpCookieStore.getAllCookies { cookies in ...} is asynchronous and too slow to grab hold of them. And even when loading the response’s mime ‘text/HTML’ payload with • myWebview.loadHT

Hi Quinn, I’ve been tracing the cookie issues for over a month now and I am able to reproduce and remedy all test cases 100%. I do have a dedicated test environment with utility buttons in the UI that let me e.g. log the cookieStore, empty the cookieStore etc. All WKWebview delegate methods and cookieStore observers are in place and log to the console when they fire. So the 2 take away test scenarios for you are these: ——————————————————— SCENARIO 1: ——————————————————— • starting the test environment • totally resetting the cookieStore by deleting all cookies • logging the cookieStore shows that it is empty • quitting the test environment • re-loading the test environment • environment is loading a test webpage from the internet with: — myWebview.(URLRequest) • the page loads correctly • the response-header’s ‘Set-Cookie’ field requests 3 cookies to be set • the WKWebview sets 3 cookies (as requested in the response-header’s ‘Set-Cookie’ field) • the didC

Hello Folks Have you got this to work ? I'm trying to setup a new SSO Extension but it does not work at all. Here is what I did : 1) I have followed the steps on the Tech Talk to configure the MDM payload in Airwatch. 2) I have installed Debug profiles that apple suggested for troubleshooting 3) I have created a dummy Identity provider. a. I understand that we need to setup a URL that will be detected by iOS and redirected to the extension. I have created a simple webpage in a valid/secured webserver and used that URL as my IdP b. In the dummy website, I have created the .wellknown/* file c. I have triggered the sysdiagnose command on my iPad. The authsrv entry seems fine. I guess it is because the Apple CDN can successfuly access the well known file... I'm not sure because I have not found a solid documentation on how this is supposed to work anywhere. d. The MDM settings are sent to the device properly. e. I have tried opening the device console but I could not see any useful information there, even after i

I have the same issue. I asked for in apple support, they said: clean your cookies, try on different browsers, on different PC's... Nothing works! They didn't answerd my last email, in that I attached several screens captures and explained my problem. I'm very disappointed with apple... :(

Your problem may be linked to the 7 days cap on localStorage introduced in iOS/iPad 13.4 Here is a link to a blog post from webkit : Full Third-Party Cookie Blocking and More - https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ Did you try using service workers ? I wonder if service workers could prevent data loss in PWA Hope I helped.