ASWebAuthenticationSession cookie

Hello Experts,What is the best way that Session information (Cookies) be shared between SFViewContoller and WKWebView; Is it possible in one way or the other? I read that SFAuthenticationSession could be used to share the session information to the app - but need any further insights like Session sharing between WKWebView and SFViewController and SFViewController and WKWebView etc. Any expert advice is greatly appreciated. Thanks

I am using OpenId.AppAuth library to perfrom the OpenId authentication against OKTA for my Mobile application.While setting up the Login part was really easy by showing the SFAuthenticationSession prompt and redirecting to OKTA.I'm stuck up with the Logout though. I have tried to Delete all the cookies for my okta IDP url, however it looks like the user is stuck at login.Is there any solution to resolve this or a workaround?

I built a player demo yesterday which I logged into and it worked great:https://s.codepen.io/leemartin/debug/bKEeZLFlash forward to today and the console is showing the following error:Uncaught SyntaxError: Invalid regular expression: /(?:^|;s*)Ag/zlbh4X32PLS+19Sv+ZlRv1OV8zxQZIMvaZ280bApwe9ljw+Xg+7TTwGiV3ZzcvWYogiEdYX+fSiRLWUiEi++IeqXZtkP9hUmg8B2AXlrWBOaoUfgu9wjGXJru7gFVpeoU6T2ZyALhaRcesnDVkznluIjiGTPta3ws3IQMYrBNzcAMiz5YngE4hn+P4Tci+domaZcK71jmC6l3yrGo2eiQvDy+aA6m/9/y6mdZRIWJsflK1A==.s=([^;]*)/: Nothing to repeat at new RegExp (<anonymous>) at Object.t.getCookie (musickit.js:13) at StoreKit._migrateStorageItem (musickit.js:13) at StoreKit._getStorageItem (musickit.js:13) at StoreKit.get [as storefrontCountryCode] (musickit.js:13) at new StoreKit (musickit.js:13) at new MusicKitInstance (musickit.js:13) at configure (musickit.js:13) at HTMLDocument.<anonymous> (musickit.js:13) t.getCookie @ musickit.js:13 StoreKit._migrateStorageItem @ musickit.js:13 StoreKit._getStorageItem @ musickit.js:13 get @

Ajax cross origin requests are failing from WKWebview with the error Preflight response is not successful. XMLHttpRequest cannot load (the url) due to access control checks.Error in console: Preflight response is not successful. XMLHttpRequest cannot load (the url) due to access control checks.Here is the request log caught by charles:URL https://www.xxxxxx.comStatus FailedFailure SSLHandshake: Remote host closed connection during handshakeResponse Code -Protocol HTTP/1.1SSL TLSv1.2 (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) [h2]Method CONNECTKept Alive NoContent-Type -Client Address /xx.xx.xx.xxRemote Address https://www.xxxxxx.com/xxx.xxx.xxx.xxxConnectionConnection #1765093527TimingRequest Start Time 6/12/18 11:43:25Request End Time -Response Start Time -Response End Time 6/12/18 11:43:25Duration 127 msDNS 1 msConnect 28 msSSL Handshake 37 msRequest -Response -Latency -Speed 1.64 KB/sRequest Speed -Response Speed -SizeRequest 213 bytesHeader 213 bytesQuery String -Cookies -Body -Uncompressed Body -Co

Hi,The Safari (MacOS/iOS) does not seem to process the cookies on websocket? We use secure websocket (wss) from javascript to open a connection to the wss server. On reply of the handshake negotiation, we attach cookies as part of the response for Connection Upgrade (http response code 101). We have double checked the response in the safari developer tools's network traffic and confirm that the cookies are part of the response. When we connect to the same wss server the second time, the request is not sending the previously received cookies. The attributes for the cookies are HttpOnly, Secure, SameSite=Strict. Is this behavior documented somewhere?We can confirm that the above setup works fine on Chrome/Firefox.Thanks.EDIT: If we remove the HttpOnly flag, then Safari (MacOS/iOS) works as expected, but we do need HttpOnly to prevent script access of the cookie.

Hello,I'm having a problem when using a kernel extension that should filter network traffic. - The kext (through the sftl_filter) starts to filter all packets, and sends them to a process in userspace - The client performs some operations (in this case, it simply sends the packet data back to the driver unmodified) - The driver re-injects the modified packet back into the network streamIncoming data works great. However, uploading data larger than 500kb results in an abruptly closed connection. Smaller files can be uploaded without issue. This is via any protocol, tested on ftp, http, https, etc.Simplified driver code:errno_t tl_data_fn(void *cookie, socket_t so, const struct sockaddr *addr, mbuf_t *data, mbuf_t *control, sflt_data_flag_t flags, FilterSocketDataDirection direction) { if (check_tag(data, gidtag, FILTER_TAG_TYPE, direction == FilterSocketDataDirectionIn ? IN_DONE : OUT_DONE)) { return 0; } if (!cookie) return result; filter_cookie *f_cookie = get_filter_cookie(cookie)