> On Apr 12, 2016, at 9:20 AM, Torsten Curdt <[email protected]> wrote: > > Cookie headers are added later. I haven’t used WKWebView, but when using an > NSURLSession the cookies aren’t part of the NSURLRequest, but get added when > the request is sent. > > Hm - but shouldn't they be available in the response at least?
You’ll see a “Set-Cookie:” header in the response, at least with an NSURLSession. > WKWebView runs in a separate process, which has its own cookie storage. > > And there is no way to access that storage yet? In general it’s a security policy that processes can’t see each other’s cookies. In the case of WKWebView, it appears to share cookies with the Safari browser — I’ve noticed that if I’m logged into YouTube in Safari, then if I go to a YouTube page in an app like Feedly that uses WKWebView, I’m logged in there too. > I want read and ideally restore a cookie that holds a website authentication. I suspect that WKWebView may be deliberately making this impossible, for security reasons. In the above example, I have better security if Feedly doesn’t have access to my YouTube session cookies, because that means Feedly can’t use them to independently send HTTP requests to youtube.com authenticated as me. (Now, I don’t know this for sure. I haven’t used the WKWebView API myself, and I’m not an expert in browser security, which is a really complicated topic.) On OS X I’d suggest using regular WebView instead, since it runs in-process and gives you access to all the state including cookies. On iOS, I’m not sure if UIWebView will suffice … its API is very limited, but you should be able to get to its cookies using NSHTTPCookie. —Jens _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
