Does anyone else have issues with cookies in WKWebview on iOS 13? It worked on iOS 12.We need our app which runs in WKWebview on a custom protocol (custom://localhost) to call servers with cookies which allow this origin. The login returns a cookie but it is not used for subsequent requests.This webkit bug is related: https://bugs.webkit.org/show_bug.cgi?id=140205
Search results for
ASWebAuthenticationSession cookie
1,295 results found
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Any update on this issue? Was anybody able to resolve it? A similar issue on Safari gets resolved by unchecking Prevent cross-site tracking. We could see cookies shared in request. But on native mac client using WKWebview, there is no way we can do it.
Topic:
App & System Services
SubTopic:
Core OS
Tags:
Safari by default discards cookies set in an iframe unless the host that's serving the iframe has set a cookie before, outside the iframe. Safari is the only browser that does this.
Topic:
Safari & Web
SubTopic:
General
Tags:
I have an iframe on my page. As Safari blocks 3rd party cookies, I am trying to use the Storage Access API as suggested here under 'Developer Guidance': https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/. I have copied the following code from here https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API/Using#Accessing_a_user's_cookies_in_an_embedded_cross-origin_iframe:<script type=text/javascript> window.addEventListener('load', () => { document.getElementById('test-button').addEventListener('click', () => { document.hasStorageAccess().then(hasAccess => { console.log('hasAccess: ' + hasAccess); if (!hasAccess) { return document.requestStorageAccess(); } }).then(_ => { console.log('Now we have first-party storage access!'); document.cookie = foo=bar; console.log(`document.cookie: ${document.cookie}`); }).catch(_ => { console.log('error'); }); }); });</script><button id=test-button>Test</button>Browser console output:[Lo
Hello, I'm still not getting the name and email from Sign in Flow. My application is implemented in .Net Core 3.1 using the OpenIdConnect. I've specified the scopes as following but when getting the code and idtoken, not user data is added. .AddOpenIdConnect(Apple, async options => { options.Scope.Clear(); options.Scope.Add(name); options.Scope.Add(email); ... } .. options.Events.OnAuthorizationCodeReceived = async context => { // no user object within the idtoken } The authentication cookie is generated but can't proceed with new account creation. I'm also using the ExternalLogin structure OnGetCallbackAsync. The url seems to have all required info as explained in this ticket. Is someone facing same issue? Thanks
Topic:
App & System Services
SubTopic:
General
Tags:
We eventually resolved this by launching out to Safari instead of using webviews inside our app. Per this link: https://developer.apple.com/app-store/user-privacy-and-data-use/ If tracking occurs within a webview inside an app, do I need to use the AppTrackingTransparency prompt? Yes. If you are using a webview for app functionality, it should be treated the same way as native functionality in your app, unless you are enabling the user to navigate the open web. So if you plan on using a webview to display the content inside your app, and that content uses cookies, you will need to display the ATT popup or you will be rejected. We switched to launching out to Safari instead of keeping them in-app, and we were promptly approved, no need for ATT since our app was no longer able to track the user across sites or apps. Hope that helps.
Topic:
App Store Distribution & Marketing
SubTopic:
General
Tags:
Hello meaton, I'm working with loula on the same project. The cookies are set on the same domain, so we are not using any third party cookies. This issue is happening in a completely hazardous way so we are not able to reproduce it on our devices. Moreover, we cannot provide an instruments trace since it's affecting our clients (end-users). How can we proceed in this case please ? Regards
Topic:
Privacy & Security
SubTopic:
General
Tags:
I'm having same issue. Any idea if WKWebview support third party cookie or any way to enable it?
Topic:
Safari & Web
SubTopic:
General
Tags:
thanks so much for your input! So when you talk about bugs are investigated for URLSession and WKWebView I can assume that those APIs are expected to honor NSPinnedDomains? URLSession, yes. WKWebView, I do not know. Last I knew this point was being investigated by that team. Regarding: What about ASWebAuthenticationSession or SFSafariViewController? Should NSPinnedDomains be honored here theoretically? At least in my testing, I was not able to make it work for SFSafariViewController so I even didn't bother to try for ASWebAuthenticationSession I do not have an answer here either. The best recommendation I can provide is if WKWebView is determined to work then I would try NSPinnedDomains with ASWebAuthenticationSession and SFSafariViewController also. If this is not determined to work then I would file Enhancement Requests for these APIs to work with NSPinnedDomains. Matt Eaton DTS Engineering, CoreOS meaton3@apple.com
Topic:
App & System Services
SubTopic:
Core OS
Tags:
Hi Matt, thanks so much for your input! So when you talk about bugs are investigated for URLSession and WKWebView I can assume that those APIs are expected to honor NSPinnedDomains and Apple eventually will provide fixes, right? What about ASWebAuthenticationSession or SFSafariViewController? Should NSPinnedDomains be honored here theoretically? At least in my testing, I was not able to make it work for SFSafariViewController so I even didn't bother to try for ASWebAuthenticationSession
Topic:
App & System Services
SubTopic:
Core OS
Tags:
When calling the authorization endpoint, after redirection, the cookie is not sent to the authentication server by Safari. The cookie header is empty. If you have an Instruments Trace of this action or a Charles Log I would add it to a bug report. This may be expected if you are relying on third party cookies during your redirect workflow, but the fact that it is working inconsistently sounds like it's grounds for a bug report. Matt Eaton DTS Engineering, CoreOS meaton3@apple.com
Topic:
Privacy & Security
SubTopic:
General
Tags:
Hello, Thanks for your response. The upgrade to iOS 14.5 fixed the issue only for some users. Not for all of them. I specified the user-agent just to show you that the user who still experience this issue has upgraded to iOS 14.5. Here are the details regarding the circumstances in which the problem occurs: An in-app browser tab is opened (ASWebAuthenticationSession) to let the user login to our application (OIDC flow) The user authenticates and the authentication server redirects him/her (with a 302) to the authorization endpoint with a set-cookie header containing the session cookies (set-cookie: session=xxxxxxxxxx; path=/; expires=Thu, 20 June 2021 20:25:45 GMT; samesite=none; secure; httponly) When calling the authorization endpoint, after redirection, the cookie is not sent to the authentication server by Safari. The cookie header is empty. What is strange is that this only affects some iOS users on different versions including 14.5 ... Regards,
Topic:
Privacy & Security
SubTopic:
General
Tags:
Hi Scott, We have a similar issue with safari an cookies that we set up on client side. you find a solution?
Topic:
Safari & Web
SubTopic:
General
Tags:
Using the following javascript code to set a cookie in Safari results in an incorrect expiry date being set on the cookie. The same code produces the correct result in Google Chrome. document.cookie = cookie_name=1615209245; expires=Tue, 08 Mar 2022 13:14:05 GMT; path=/; This code produces a cookie with an expiry date of March 8, 2022 in Google Chrome as expected, but incorrectly as March, 16, 2021 in Safari. Is this a known issue? What can I do to get the correct result?
ASWebAuthenticationSession does not require any modification in your Info.plist. This exception happens because the value that was passed to callbackURLScheme contained either a : or / character. In most cases, this means you passed something like myscheme://, which is not valid. The correct value to pass in this case is just myscheme (no trailing ://).
Topic:
App & System Services
SubTopic:
Core OS
Tags: