ASWebAuthenticationSession cookie

Ok I managed to solve the problem :OO Leaving the answer to someone that may have same problem in the future :D In my manifest file I had to change background.service_worker to background.scripts. Apparently service_worker runs on the separate thread and has limited browser context hence no access to the cookies If you use background.scripts instead it will make extension generate persistent background page that has a possibility to pickup the cookies :D Everything works out of the box now :D

Thanks for response. This will mean that I have to start develop in swift which I am trying to avoid. I found other very similar extension that seems to work the same way. The difference that I see between ours is that when I enter Develop > Web Extension Background Content: 3rd Party Extension I can see generated_background_page.html in the Sources Tab that loads the background script. I can also see all the devtools tabs like on any other website. In Networking tab can see all the requests made. Interesting thin is that if I make the fetch request from the Console of this background script to our service... the cookie gets attached automatically and I am able to use the api. My Extension While when I enter background script of my extension I can see only three dev tools tabs: Console, Network and Sources. In Sources I have only service-worker.js file and none of html files. On the Network tab I can't see any requests send for example when I open extension popup yet.. in Console I can see all the

The issue has been resolved. There was some additional layer of cookies access protection on our website and it blocked reading cookie with CRSF token. There is no issue within WebKit and iOS then. Thread can be closed :)

Can you please file this through Feedback Assistant, ideally with a screen recording and/or repro case? ASWebAuthenticationSession uses WKNavigationDelegate under the hood, so it should be able to catch all the same things.

The additionalHeaderFields value follows the Fetch standard's forbidden request header algorithm. Cookie is one of the forbidden fields.

Interestingly, I left a simulator running for a long while and came back to my desk and hit the authenticate button. The Safari view caused by using ASWebAuthenticationSession came up, was blank/invalid, and I got a callback from the authentication provider.. The header that caused this was: Location: myapp://auth#state=17A26C7A-AFDE-4C3B-BA89-85FAA343F0DB&error=invalid_request_object&error_description=Expired%20jwt I'm partially happy it worked at least once, but am also confused it doesn't work when it should

This is going to be a problem for a lot of people and we probably need to raise developer awareness Previously the setting would cause the Mac Address to rotate each time you connect to a wifi network; turn it off stopped that and your hardware address would be used (or perhaps the random one just stayed the same). Now for iOS and MacOS there no way to stop it rotating each time you connect to anything. The new on/off switch controls whether the address rotates while you are still connected after XX minutes. This is an absolute disaster for the following situations: Networks where you want to pin a device to an IP address via DHCP Reservations so that you can QoS traffic going to that device. Networks were you want to lock children to an IP Address so that you can parent control what those kids can do on the internet. AirPlane and Hotel Hot Spots that you buy 5 hours of usage at high speed that link to your mac address Networks with really Long DHCP lease times to ensure stablility will find that Apple Device

@Knyhuus an identical function similar to what you have in the scope of the .navigationDestination(for:) closure would be: @ViewBuilder func itemViewFor(destination: Destination) -> some View { switch destination { case .cookie: CookieView() case .milk: MilkView() } } Secondly, StateObject property wrapper should be marked private and instantiated with the View.