I am creating a Safari Web Extension. There are two calls let say, call1 and call2 which gets executed in sequence by browser, call1 gives a 302 type response and redirects to call2. When creating DNR rule for adding Cookie in the request header of call1, the same cookie gets added to the request header of call2 as well(Same is the case for other headers/custom headers as-well). Because of this the set-cookie present in response header of call1 is not sent in the request header of call2, and returns 400 response. The same setting is working fine for other browsers chrome & firefox. Is this a bug or DNR works differently for safari ? currently webRequestBlocking works in safari for manifest v3, is there any development of it getting removed just like it's removed in chrome in mv3.
Search results for
ASWebAuthenticationSession cookie
1,295 results found
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
After upgrading to Safari version 18, we encountered an issue with my extension’s background script not being able to access cookies. Previously, in Safari versions 17 and below, the extension worked as expected. Now, when the extension tries to retrieve cookies using browser.cookies.getAll(), it returns an empty list. However, if we open the extension’s developer tools, the cookies are visible and accessible. It seems that Safari only provides cookie data after the developer tools have been opened. However, after relaunching Safari and launching the extension without opening the developer tools, browser.cookies.getAll() still returns an empty list. Has anyone else experienced this? STEPS TO REPRODUCE Download this minimal app : https://www.icloud.com/iclouddrive/0bajlhnuQaG6T5NsFKXEB0U9Q#test%5Fcookies Compile test_mv2 extension (in test_cookies.getAll.zip). Launch test_mv2.app and activate extension. Click on the extension's button (browserAction). Open the developer tool
I discovered the following comment in a relevant discussion: https://developer.apple.com/forums/thread/761323?answerId=827607022#827607022 By using the storeId, we were able to successfully retrieve the cookies. async function getAllCookies(name, url) { const stores = await browser.cookies.getAllCookieStores(); var cookies = [] for (const store of stores) { const cookieOfStore = await browser.cookies.getAll({ name, url, storeId: store.id }); cookies.push(...cookieOfStore); } return cookies; } await getAllCookies(geo, https://apple.com);
Topic:
Safari & Web
SubTopic:
General
Tags:
Apology for repost. I needed to fix the tags for original thread. https://developer.apple.com/forums/thread/777159 On iOS 18.3, I noted that partition HTTPCookiePropertyKey: StoragePartition is not observed to be set for cookies returned from the wkwebview cookie store. Now on 18.4 beta 4 we are now seeing those same cookies are populated with a partition property. Is there documentation for this change? Is it intended to be suddenly populated in 18.4? Now that partition property is set, HTTPCookieStorage.shared.cookies(for: serverUri) doesn't seem to return the expected cookies correctly. For context, we are using the cookies extracted from wkwebview, setting them in HTTPCookieStorage.shared and using URLSession to make network calls outside the webivew. Works fine once I forcefully set partition on the cookie to nil. More details on what the cookie looks like here: https://feedbackassistant.apple.com/feedback/16906526 Hopefully this is on your r
Hi I am not entire sure what you mean by that - do you have a link this api? In our app we are using for out cookie operations. https://developer.apple.com/documentation/foundation/httpcookiestorage . Building on xcode 16 beta 2 doesn't make a difference.
Topic:
App & System Services
SubTopic:
Networking
Tags:
In our Mac application, we are creating a web-socket connection using NWConnection and we are able to successfully establish the connection and read/write data from both sides. We have auth tokens which are sent in headers of NWProtocolWebSocket.Options to the server. If token is good, server accepts the web-socket connection. As per RFC 6455, if server does not want to accept the connection for any reason during web-socket handshake, it returns 403 status code. In our case, if cookies are not valid, server returns 403 during web-socket handshake. However, we could not find a way to read this status code in Network.framework. We are only getting failed state with NWErrorwhich is .posix(53) but there is no indication of the status code 403. We tried looking into protocol metadata on NWConnection object and they are nil. We tested the same using URLSessionWebSocketTask where in failure callback method, we could see 403 status code on task.response which means client is getting the code correctly from s
I'm simply trying to use a proxy to route a http request in Swift. I've tried using a URLSession Delegate but that results in the same issue with the iOS menu. proxy format: host:port:username:password When I run the code below I am prompted with a menu to add credentials for the proxy. I closed this menu inside my app and tried the function below again and it worked without giving me the menu a second time. However even though the function works without throwing any errors, it does NOT use the proxies to route the request. I've spent days on this and the only solution I found was using a NWConnection but this is super low level and now I need a shared session to manage cookies. If you want to see the NWConnection solution I made its here func averageProxyGroupSpeed(proxies: [String], completion: @escaping (Int, String) -> Void) { let numProxies = proxies.count if numProxies == 0 { completion(0, No proxies) return } var totalTime: Int64 = 0 var successCount = 0 let group = DispatchGroup() let queu
Well, that’s not good. I ran your test and was able to immediately reproduce the problem. [quote='777999021, fastred, /thread/777999, /profile/fastred'] Already submitted as FB17006003. [/quote] Thank you! I checked on your bug and the relevant folks have seen it. Your bug mentioned HTTP storage, so I tweaked your code to use an ephemeral session and the problem went away. let session: URLSession = { return URLSession(configuration: .ephemeral) }() Ephemeral sessions disable three standard things: cookie storage, the URL cache, and credential storage. So I tried creating a default session with those disabled: let session: URLSession = { let config = URLSessionConfiguration.default config.httpCookieStorage = nil config.urlCache = nil config.urlCredentialStorage = nil return URLSession(configuration: config) }() Annoying, that didn’t fix the problem. So the ephemeral session is disabling something beyond those three standard things. And that’s me out of obvious ideas )-: Clearly this is a bug that the
Topic:
App & System Services
SubTopic:
Networking
Tags:
On iOS 18.3, I noted that partition HTTPCookiePropertyKey: StoragePartition is not observed to be set for cookies returned from the wkwebview cookie store. Now on 18.4 beta 4 we are now seeing those same cookies are populated with a partition property. Is there documentation for this change? Is it intended to be suddenly populated in 18.4? Now that partition property is set, HTTPCookieStorage.shared.cookies(for: serverUri) doesn't seem to return the expected cookies correctly. For context, we are using the cookies extracted from wkwebview, setting them in HTTPCookieStorage.shared and using URLSession to make network calls outside the webivew. Works fine once I forcefully set partition on the cookie to nil. More details on what the cookie looks like here: https://feedbackassistant.apple.com/feedback/16906526 Hopefully this is on your radar?
@DTS Engineer I am targeting multiple web servers that I don't have control over, but each thread/task will only target one specific server, so there is no need to manage cookies for multiple sites at the same time. These web-servers use a shared service so all the request/responses will be similar across. I could use the NWConnection solution that I already have which works but just unsure how to get the Set Cookies from responses and add them to next requests.
Topic:
App & System Services
SubTopic:
Networking
Tags:
Have you tried using the Cookies Store API in iOS 18.4 as it has become available?
Topic:
App & System Services
SubTopic:
Networking
Tags:
We have some third-party SDKs do not support arm64 simulator, so we excluded arm64 for Any iOS Simulator SDK in Excluded Architectures. But in this case, ASWebAuthenticationSession will display abnormally. We submitted FB14853757 during the beta period, but have not received any response. This issue still exists in the official version. I hope it can be resolved. Thank you!
TLDR: I’m searching for a possibility to allow the usage of passkeys and hardware keys for any website in a wkwebview INFO: The browser is macOS ONLY Hi, I couldn’t really find documentation or forums posts on how to implement Webauthn for signin or hardware security keys for a second factor. Or rather where those events are triggered to be handled. In Safari you have that popover, that lets you either authenticate through Passwords or with a security key. When I visit webauthn.io for testing and click either register or authenticate I get Told not to present authorization sheet: Error Domain=com.apple.AuthenticationServicesCore.AuthorizationError Code=1 (null) ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 (null) If I add func webView(_ webView: WKWebView, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping @MainActor (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) and func
CFNetwork None CFURLResponseGetRecommendedCachePolicy None 0 CFNetwork None CFHTTPCookieStorageUnscheduleFromRunLoop None 0 CFNetwork None /_/_CFNetworkAgentMessageProcessorMain None 0 CFNetwork None CFURLDownloadCancel None 0 CFNetwork None CFURLDownloadCancel None 0 libdispatch.dylib None /_dispatch/_block/_async/_invoke2 None We've observed intermittent crashes in our production environment, exclusively affecting customers running macOS 10.15 and 11. The crash logs consistently show a stack trace involving CFHTTPCookieStorageUnscheduleFromRunLoop and CFURLDownloadCancel within the CFNetwork framework. This suggests potential issues with cookie storage management and/or URL download cancellation. Could the team please analyze these crash logs and provide insights into: The root cause of the crashes. Potential race conditions or synchronization issues. Recommendations for mitigating or resolving the problem. Your assistance in resolving this issue is greatly appreciated.
I'm testing my existing web extension with the new iOS version and browser.cookies.getAll({url: https://myurl.com}) stopped working. It returns an empty array. Is there another way to get the cookies?