Hacker News Reader

Comment by joshsharp | Hacker News Reader

Sure, the cookies expire (in two weeks I think, in this case) but that doesn't invalidate the issue that the wkwebview silently shares cookies with nsurlsession, nor does it negate the confusing journey of tracking down the bug. Sheesh.

View on HN

This is exactly what users want and you are basically breaking it by not honoring the cookies.

We do not need to honour cookies when making requests to the API as we use token authentication. Even if we wanted to keep users logged in within the web view, which we don't because the web view is just for static help pages, we wouldn't want to send those to the API.

Then you should disable cookies on your API calls by setting the `httpCookieStorage` property of your URLSessionConfiguration to nil. You could also use an ephemeral configuration (which will preserve cookies set by the API in memory but won't share them with webviews), which may or may not be a good idea depending on if you're using this session for anything that should be cached to disk (e.g. downloading images).

This is the correct answer and the reason that NSURLSession really came into existence - there is a need to partition behaviors between different frameworks and subsystems and the previous NSURLConnection model relied on a smattering of process global configuration options.

I'd be surprised if AFNetworking didn't also offer the ability to create a "private" NSURLSession with custom storage objects.

I'd also recommend looking into debugging these types of issues using, eg, Charles Proxy. There's more information on logging at:

https://developer.apple.com/library/content/qa/qa1887/_index...