ASWebAuthenticationSession cookie

its been long time , apple did not introduce cookie fix for ios less than 11. if there is no solution for cookie sync for less than ios 11 then why Apple mentinoned in documentation Wkwebview available from iOS 8 😟 :@

This is a bit of a retrospective, but we have just been bitten terribly by the bug/change. We read a million articles / this forum / stackoverflow questions that all seemed to stem from cookie behavior changing in 11.3/11.4/12+, I've read this forum dozens of times. Our app got hammered by negative reviews, as users continuously kept getting logged out as the cookies stopped working consistently, and users were tweeting and calling our support center. Our QA process could not reproduce what was going on, we haven't pushed an App Store update to our app in months. Sometimes it worked, sometimes force closing worked, sometimes when you logout/login-as-another-user, then force close, and re-enter the app, you were logged in as the previous user, chaos...Tangent: I'd like to complain that in iOS that there isn't just one best WebView class. It got splintered into UIWebView, and WkWebView, and app developers had to deal with intricacies related to managing networking, and cookies with ea

Also, is there a way to capture the CFNetwork diagnostic os_log output from within our app/process …No. There are numerous difficulties in making that work [1] but I realise that it’d be a super-useful feature so don’t let that stop you from filing an enhancement request describing your requirementsPlease post your bug number, just for the record.To get CFNetwork diagnostics information from devices in the wild, am I correct in thinking we need to first setenv(CFNETWORK_DIAGNOSTICS, 3, 1); in main() … Correct.and probably put this behind some kind of remote flag or Settings.app setting to avoid doing it for all our usersIf you put this in a production build, make sure that the UI informs the user of the privacy risks involved in enabling it.then have the appropriate users install the profileThat step is not necessary.capture a sysdiagnose and send it to us?Yes.Without setting the env var will there be anything useful in a sysdiagnose … ?Yes, although it’s hard to say whether that will help you debug this ques

We have the same situation in which we must be aware of the redirect chain in order to determine if our extension should stand down and not inject any content within the page for complaince with our partners terms.7. Software Publishers must recognize and respect publisher-driven traffic immediately prior to the software dropping a cookie. Specifically, all software must recognize CJ domains and afsrc=1 codes in affiliate links. When a CJ domain or the afsrc=1 code is detected, the software may not operate or redirect the consumer to the advertiser site using the Software Publisher's PID.It appears that there are no longer any events (specifically navigation events) coming from the browser beyond just messages that can be dispatched from the injected script which occur too late in the flow as injections do not occur during server side redirects. We have investigated the use of validateToolbarItem(in:validationHandler) with SFSafariExtensionHanlding however this does not fire during redirects even if

Hi Steve,I've actually raised a TSI with Apple over this issue and here's what we got back.Thank you for contacting Apple Developer Technical Support (DTS). We have reviewed your request and have concluded that there is no supported way to achieve the desired functionality given the currently shipping system configurations.If you would like for Apple to consider adding support for such features in the future, please submit an enhancement request via the Apple Bug Reporter tool at <https://developer.apple.com/bug-reporting/>.In the meantime, you can try injecting a script into the webpage that checks the window.location.href and redirects after the fact if there is no affiliate code on the URL to start with.Hopefully this helps.The problem with his potential solution (as I understand it) is that the redirect has already happened by the time the code is injected and therefore it get's missed.I notice from your post that your refering specifically about CJ affilates, we've even contacted CJ to see if there

just clear old cookies before adding new cookies into the WKWebView. You will get succeed.WKWebsiteDataStore.default().fetchDataRecords(ofTypes: WKWebsiteDataStore.allWebsiteDataTypes()) { records in records.forEach { record in WKWebsiteDataStore.default().removeData(ofTypes: record.dataTypes, for: [record], completionHandler: {}) print([WebCacheCleaner] Record (record) deleted) } }

Hi Quinn -With the suggested configuration, we can hit the server and log in page, but once a log in attempt is made, it produces the below diagnotistic output simulating iPhone 7 (12.1) is below. It is actually the same error we get today for the existing app in the App Store that is configured with ATS disabled.2018-11-28 08:41:42.637467-0700 Vistar[35138:2786742] CFNetwork Diagnostics [3:363] 08:41:42.637 { LoaderWhatToDo: (null) Request: {string = https://myvistar.vistar.com/CGI-BIN/lansaweb?webapp=WB001M01+webrtn=verifyLogin+ml=LANSA:XHTML+partition=PRX+language=ENG, encoding = 134217984, base = (null)} CachePolicy: 1 WhatToDo: originload CreateToNow: 0.00029s } [3:363] 2018-11-28 08:41:42.637798-0700 Vistar[35138:2786744] CFNetwork Diagnostics [3:364] 08:41:42.637 { AddCookies Continue: request POST https://myvistar.vistar.com/CGI-BIN/lansaweb?webapp=WB001M01+webrtn=verifyLogin+ml=LANSA:XHTML+partition=PRX+language=ENG HTTP/1.1 HTTPProtocol: Task: 787c00 } [3:364] 2018-11-28 08:41:42.638273-0700 Vistar[

I have a radar open ( rdar://36296263 ) in regard to the poor UX of SFAuthenticationSession/ASWebAuthenticationSession. I would suggest logging a radar yourself as the more radars that are opened for a given issue, the more likely Apple will address it.

Thanks Quinn,I'm working on getting a packet capture if I can, and am adding in more logging to our own tools to see if I can suss any more details out of what is happening. It feels like a network issue, but we can't replicate it on demand at the customer site or in our labs.The TLS events I am interested in are 1, 2, 11, 12, 14, and 20. More than anything I guess I'm looking for a sanity check that I'm interperting these logs properly.Annotated, and redacted, logs below. This Mac is on 10.13.6 and Wi-Fi.Here we see the program flow from the user clicking Sign In all the way to the network disconnect.SecurityAgent: (NoMADLoginOkta) [menu.nomad.login:UI] Sign In button clicked SecurityAgent: (NoMADLoginOkta) [menu.nomad.login:UI] Format user and domain strings SecurityAgent: (NoMADLoginOkta) [menu.nomad.login:UI] Using managed domain SecurityAgent: (NoMADLoginOkta) [menu.nomad.login:UI] Removing domain from username SecurityAgent: (NoMADLoginOkta) [menu.nomad.login:NoLoSwiftMech] Checking for local username S