ASWebAuthenticationSession cookie

PLATFORM AND VERSION iOS Development environment: Xcode 16.2, macOS 15.3.2 Run-time configuration: iOS 15-18 This happens in iOS, and leads to to the hybrid home page showing users as wrongly unauthenticated, since the at cookie is missing. For context, we have a JWT token that is stored in the Keychain, and on app launch, before any WKWebViews are created, we synchronize this to the WKWebsiteDataStore as an at cookie. We have analytics instrumentation on our websitef to show that WKWebView randomly refuses to send out any cookies. – The following is a snippet from an explanation to the WebKit Slack: We are having an issue on iOS, in which WKWebView loads pages (and even subsequent reloads) without any cookies, even though we have stored cookies in WKWebsiteDataStore.default() before hand right after application launch and becoming a key window. We reference this object, store it as a singleton, (as well as a process pool), and then all webview configurations are i

We have a multi-tenant EdTech platform serving over 1500 clients, each with a unique domain (e.g., client1.eduapp.com). We use WKWebView in a native shell. Due to WKAppBoundDomains restriction, we can't dynamically list all domains. How can we support dynamic tenants while maintaining cookie persistence Can Apple suggest a best practice or alternative approach for apps using WebView/PWA shell architecture across multiple client domains? Problem: We cannot predefine all 1500 domains in WKAppBoundDomains due to limitations. As a result: Service workers fail to register, breaking PWA functionality Ex: Offline.

Safari Extension Error: “Non-persistent background content cannot listen to webRequest events.” after macOS 15.4 / Safari 18.4 Update We’re seeing the following error in the Safari Extensions tab after updating to macOS 15.4 and Safari 18.4: “Non-persistent background content cannot listen to webRequest events.” This error did not appear prior to the update, and we haven’t found any official documentation stating that webRequest API is no longer supported in Safari. In our extension (Manifest V3), we are using the webRequest.onHeadersReceived callback to intercept response headers and read updated cookies. While the functionality itself still works as expected. we’re able to access the response headers and this error is now shown in the Extension settings page. We are not seeing this issue in other browsers (Chrome, Firefox) using the same Manifest V3 setup. Is there any plan to deprecate webRequest support in Manifest V3 for Safari? We’d appreciate any clarification or guidance on how to handle this

We’re seeing an issue in our Safari Web Extension where not all cookies from the Set-Cookie response header are accessible. We are using macOS 15.4 and Safari 18.4. In the webRequest.onHeadersReceived callback, the Set-Cookie header returned by Safari only includes some of the cookies set by the server. If multiple Set-Cookie headers are present, we seem to receive only a partial list, some cookies are missing entirely. In Chrome and Firefox, the same callback provides all cookies set by the server without issue. We are looking for assistance in fixing these issues and having our Safari Extension function the same as it does in Firefox and Chrome.

We’re encountering an issue when trying to add non-standard headers to outgoing requests using Declarative Net Request (DNR) rules in our Safari Web Extension. Tested on macOS 15.4 with Safari 18.4. Specifically, when attempting to add a custom header such as X-Custom-Header using a DNR rule, the header does not appear in the request. We are able to add standard headers like Authorization and Cookie to the request successfully using the same method. This behavior suggests that Safari may be filtering or blocking non-standard headers when set via DNR rules, unlike other browsers. In Chrome and Firefox, the same rule adds the X-Custom-Header header without any issue. We are looking for assistance in fixing these issues and having our Safari Extension function the same as it does in Firefox and Chrome.

When a DNR rule is set for a specific URL and the request receives a server-side redirect (e.g., 302) to a different URL that does not match the urlFilter, the rule still seems to apply to the redirected request. We are using macOS 15.4 and Safari 18.4. For example, consider two sequential calls: call1 and call2. call1 triggers a 302 redirect to call2. A DNR rule is created to add a Cookie header to call1 based on its URL. Unexpectedly, the same cookie is also added to call2, even though call2's URL does not match the rule's urlFilter. This results in the Set-Cookie response from call1 being ignored, and call2 receiving the manually set cookie instead—leading to incorrect behavior. This issue doesn't occur in Chrome or Firefox, where the rule is not applied to the redirected request if the URL no longer matches. We are looking for assistance in fixing these issues and having our Safari Extension function the same as it does in Firefox and Chrome.

We are planning to use our internal IdP (PingFederate) for authentication of end users in their iOS apps using ASWebAuthenticationSession. Initial tests are successful, but the user is prompted for every login (and logouts) with a consent dialogue box: “AppName” wants to use “internal domain-name” to Sign In This allows the app and website to share information about you. Cancel Continue” Let’s say that our top-level domain is “company.no”, where our IdP is placed at “idp.company.com”. I have seen examples where the Associated domains entitlement points to the idp as a webserver for serving the JSON output AASA file. In this case that would be: authsrv: idp.company.com Anyone with experience implementing this structure with the IdP as webserver for serving the JSON output? Our problem is that trying to use the IdP as webserver for this purpose is that it is very complicated to modify the IdP’s webserver configuration. Also, this modification needs to be re-done every time we need to upgrade the IdP. M

1 Steps to reproduce the issue Login in Account/ Go to https://appstoreconnect.apple.com/. Open users and permission. Open integration tab. Select API App Store Connect. Click Team Keys. Click Generate API Key. Input name MyTracker, role: Admin. Catch 401 status from Api and reload page. 2 Approximate date and time the error occurred (including the time zone) Errors were on: Tue, 08 Apr 2025 06:46:20 GMT Tue, 08 Apr 2025 06:16 GMT 3 Curl example curl 'https://appstoreconnect.apple.com/iris/v1/apiKeys' -H 'accept: application/vnd.api+json, application/json, text/csv' -H 'accept-language: ru,en;q=0.9' -H 'content-type: application/json' -H 'cookie: s_fid=6541AF9921104763-34AED62C094B846F; s_vi=[CS]v1|33F13BA8D23DEE97-4000106C0143A1DE[CE]; geo=FR; s_cc=true; s_sq=%5B%5BB%5D%5D; dslang=RU-RU; site=RUS; myacinfo=DAWTKNV323952cf8084a204fb20ab2508441a07d02d32f8cc74eda7d840cbff380867b48ae61921e5fb806faa4770c7d1e65515527094328232e18ce49ddca803e8229f778c921e2d83762d354b4902f941bae81b0e1f738b89100ca0e82a190

Apologies if this isn't tagged right but dev tools and services seemed the most appropriate since this is related to the workbench Ad Tester tool. I'm seeing a behavior where the preview link is not being generated. Specifically, I am seeing a POST request to the following URL consistently fail: https://iadworkbench.apple.com/adtester/api/v1/ads/previewLink?orgId=1127861 Variations/scenarios I have tried so far: All possible ad format choices on all possible devices All options for the placement type Both third party and uploaded creative sources Uploaded creative sources appear to be failing to upload as well A simple div with a hello world content fails as a third party creative source Multiple apple accounts I created a new account specifically to test if my primary apple ID was experiencing issues with this Multiple browsers I have tried multiple versions of Chrome/Firefox/Safari I tested with and without browser extensions to determine whether an extension was interfering or not Clearing session/local st

It looks like the capability identifier, merchantIds, can now officially be interacted with using the /v1/merchantIds endpoint. Curious if /v1/appGroups or /v1/cloudContainers will be added to the official API too. Fastlane currently supports these endpoints with the cookies authentication system. Unlike many endpoints, these ones are specifically required to ensure that apps with certain entitlements have correct remote settings otherwise the xcodebuild will fail. Appreciate any input here, thanks!

The endpoint /v1/betaAppReviewSubmissions supports post and get requests for creating and querying beta app store review submissions but I would like to be able to withdraw submissions by making a delete request like you can on the website and when using cookies authentication to the same endpoint with tools such as with Fastlane. Is this API intentionally missing in the official API or is it something that could be added?

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.

We are seeing network errors in Outlook mail on iOS and MacOS safari browsers. As per current investigation, we notice these network error when the user tries to use outlook after leaving it open on Safari for a while. Observations: Issue present in both MacOS and iOS safari. Issue is not present in other webkit browsers like brave and edge on iOS. Issue is reproable on both mini and big owa on safari browser. Issue is not related to post requests being sent in different packets on safari browser. Requests are only blocked for outlook.office/outlook.live domains What does not fix this issue? Reloading the application Clearing cookie, local storage or session storage Unregistering service workers Redirecting to a different page and coming back to outlook domain Re authenticating the users What fixes this issue? Reconnecting to wifi or mobile network Reconnecting vpn Removing safari from background and reopening Flushing the dns in setting