ASWebAuthenticationSession cookie

I had the same problem. We fixed the issue by specifying the Expires or Max-Age of the cookie. iOS has the problem of losing cookies without Expires or Max-Age that exist in web views in the background during memory cleanup. I was able to find out from the cookie test on iOS safari. I haven't tested it in all versions of iOS, but it happens in iOS 15 and later.

You do not answer to reviewer's comment: collects cookies for tracking after the user asked you not to track them Is that the case or not ? Even if user has accepted cookie banner request, if he/she denies ATT, you cannot do any tracking.

Starting with the quick question: I've noticed that in every crash report's stack trace, there is always a thread that includes JavaScriptCore. Could you please take a look at what it's doing? Basically, nothing? Strictly speaking, it's blocked in scavenger_thread_main, which is part of libpas a custom malloc implementation WebKit uses. WebKit has a nice write up of libpas and The Scavenger, but the direct answer is that it's just idling waiting for the next time it runs. I would like to ask, why would this problem occur when sorting cookies? What operation is this function performing that leads to the crash? The term sort there is slightly misleading. It's sort as in compare these two cookies and tell me which should be first, not please sort this big list of cookies. The actual crash is caused by dereferencing a pointer that references the domain name and which should not be NULL. It's doing that as part of inserting a cookie into the cookie store, which is what

Thank you Kevin Elliott! I would like to ask, why would this problem occur when sorting cookies? What operation is this function performing that leads to the crash? If the crash is caused by a specific cookie value, could you tell me which specific attribute of the cookie is causing the problem? In addition, I tried to set breakpoints for these symbols in Xcode, but was unsuccessful. Could you tell me how to correctly set breakpoints so that I can better debug this problem? I really hope to get some specific tips so that I can better solve this problem. I really appreciate your help.

Hi, First off, the reason you weren't able to symbolicate the original logs is that the library UUID is missing from the crash logs. With a bit of digging I found crash logs that included CFNetwork from both system version. Here are the original and corrected library entries: Crash 1/iOS 17.5.1 (21F90): 0x19b497000 - 0x19b873fff CFNetwork arm64e /System/Library/Frameworks/CFNetwork.framework/CFNetwork 0x19b497000 - 0x19b873fff CFNetwork arm64e /System/Library/Frameworks/CFNetwork.framework/CFNetwork Crash 2/iOS 17.4.1 (21E236): 0x18ef9a000 - 0x18f376fff CFNetwork arm64e /System/Library/Frameworks/CFNetwork.framework/CFNetwork 0x18ef9a000 - 0x18f376fff CFNetwork arm64e /System/Library/Frameworks/CFNetwork.framework/CFNetwork With the right UUIDs, both logs symbolicate to this stack: Thread 50 Crashed: 0 CFNetwork 0x000000019b534d2c cookieHeaderSort(CompactCookieHeader const*, CompactCookieHeader const*) (in CFNetwork) + 28 1 CFNetwork 0x000000019b534a1c CompactCookieArray::_mungeCookies(CompactCookieArray co

[quote='756391021, MichaellisAngi, /thread/756391, /profile/MichaellisAngi'] I am allowing a user to log in with an OAuth 2.0 Provider on the Safari browser and expecting to detect the redirect to continue the flow from the app once their credentials have securely been consumed by the IdP in Safari. [/quote] This API allows you to determine how a shortened or obscured URL might unfurl, but we intentionally restrict the returned URLs to preserve user privacy. From the use case you describe, I think you'd be better served using ASWebAuthenticationSession, as there really are not hard guarantees here. Specifically we shipped a new API for ASWebAuthenticationSession which allows specifying an https callback. let session = ASWebAuthenticationSession( url: URL(string: https://example.com/signIn)!, callback: .https(host: mycoolsite.com, path: /auth) // New API ) { callbackURL, error in guard let callbackURL else { return } signIn(using: callbackURL) } session.presentationContextProvider =

If you're adopting ASWebAuthenticationSession for signing in to your app, you shouldn't need to call matchesURL() (except maybe for debugging purposes). That method exists mainly for web browsers that implement handling of ASWebAuthenticationSession requests. To use ASWebAuthenticationSession for signing in, you probably want something like let session = ASWebAuthenticationSession(url: URL(string: https://example.com/signIn)!, callback: .https(host: mycoolsite.com, path: /auth)) { callbackURL, error in guard let callbackURL else { ... } finishMySignIn(with: callbackURL) } session.presentationContextProvider = presentationContextProvider session.start() This will open https://example.com/signIn in a browser context, and watch for a redirect to a URL that starts with https://mycoolsite.com/auth. When a page matching that URL gets loaded, you'll get the full URL in the callbackURL argument, which should have the necessary auth tokens. Note that for custom schemes, there's no n

The thirdPartyCookiesEnabled feature on the WebView is for Android only so it doesn't help with ATT. You will have to inject javascript to the webview to block third party cookies.