ASWebAuthenticationSession cookie

I am answering my own post with an update: I solved the issue. The string used to set the cookie had syntax that Safari, and Opera would not allow. That was due to a subtile and important issue with a for loop: a missing break statement. So the difference between Safari (and Opera) and Firefox, Chrome is the cookie string syntax. If secure is specified, it should be in the string by itself and not set to anything. The issue I tracked down was that 'secure=false;' was showing up in the string when it is just set by the presence of absence of 'secure' Thank you for time and attention JK

Has anyone found a fix to this? I just posted a question on a couple of ASWebAuthenticationSession issues I'm seeing and just realised that one of them looks a lot like this one (apologies for the duplicate if so).

Do you have any new info about it? We have the same problem - our app is web wrapper and the cookie is only for the session. No tracking at all. Our progress - after long ping-pong with some robot that it is cookie for session, no tracking at all and all responses were like cookies = tracking so you have to implement App Tracking Transparency. So we decided to add ATT to app and filled the form with tracked info (there is nothing tracked) and the robot answered, that we have to explain how we track the user - because we implemented ATT, so we are tracking. Exact example of Catch-22.

This is absolutely not fixed. We use the Auth0 SDK for Oauth2 authentication across various Apple devices, which on macOS wraps ASWebAuthenticationSession, and encounter this behavior relatively frequently. We see it on Monterey, across Safari, Chrome and Brave browsers. I am surprised this isn't getting more attention. The problem is pretty nasty once it triggers -- the user has no idea what is happening or why the login dialog doesn't pop up, and the calling application has no way to detect the condition. We reported it to Auth0 and they closed our bug pretty quickly -- everyone seems to understand this is Apple's problem.

Same issues here. Accepted on 14th December already. Tried everything: Cache&Cookies delete, different browsers, unchecked 'prevent cross-site...' in Safari. Nothing. Wrote to support. Baack came a general, generic answer, basically saying I have to accept that!. Really Apple?

I shared my code with my main app target and specified a custom url scheme matching the cloudkit-icloud.[containername]://authToken and I see my ASWebAuthenticationSession getting invoked with the new token. So I know that code is wired up properly and functional It is stated in the Exploring App Clips video that they do not support URL Schemes, when I have the same URL scheme specified, safari says Safari cannot open the page because the address is invalid. which makes sense if the App Clip isn't registering the URL with the system. When I try to use the https:// [advanced-app-clip-invocation-url] safari view controller is redirecting to my web page that matches the app clip url--not the app clip itself. Universal links are also explicitly not supported by App Clips either as per the same app clip video. I know there is a lot of interest in App Clips + CloudKit so I'll continue to post my findings.

I have the same problem :status: 500 content-length: 0 date: Sat, 25 Dec 2021 05:55:05 GMT set-cookie: dqsid=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpYXQiOjE2NDA0MTEzOTksImp0aSI6Iloza0htM3pKbjNPVzJFeVpmSVlpd1EifQ.vsHqu0ubLPjSmGSV1mYsWj3Jw_szTv-zLQH1iW7BVng; Max-Age=1800; Expires=Sat, 25 Dec 2021 06:25:04 GMT; Path=/; Secure; HTTPOnly access-control-allow-credentials: true access-control-allow-origin: https://appstoreconnect.apple.com access-control-expose-headers: ETag x-b3-traceid: b7b5752d682d3994 strict-transport-security: max-age=31536000; includeSubDomains; preload x-frame-options: SAMEORIGIN x-content-type-options: nosniff x-xss-protection: 1; mode=block x-apple-jingle-correlation-key: ZERDVHGSF4QEWR77LIJEFP7X5Q x-daiquiri-instance: daiquiri:13851002:mr22p00it-ztbu07032101:7987:21RELEASE200:daiquiri-amp-dsce-asc-int-001-mr x-content-security-policy: script-src 'self' *.apple.com x-daiquiri-instance: daiquiri:18493001:mr85p00it-hyhk03154801:7987:21RELEASE200:daiquiri-amp-all-shared-ext-001-mr x-

It is referenced in this video to in fact use ASWebAuthenticationSession but I haven't found any useful information in the documentation on how to get it setup with the callback yet: https://developer.apple.com/videos/play/wwdc2020/10174/?time=909

Did you manage to get an answer to this? Facing the same problem here - a webview showing content owned by the same company as the app and which has a legally required cookie panel that allows users to opt out on the webview. Apple say that we have to ask the user to opt in/out before showing the webview cookie panel opt in/out.

Hi @MobileTen, I meant not the user case where the user opted out, but the case when the user keeps opted in and is logged out by clearing the session cookie. I expect the user to stop receiving notifications while logged out without user intervention and resume receiving notifications when logged in. With a manual logout is easy, as the server is aware.