Can I set the cookies to be used by a WKWebView? Can I set the cookies to be used by a WKWebView? ios ios

Can I set the cookies to be used by a WKWebView?


Edit for iOS 11+ only

Use WKHTTPCookieStore:

let cookie = HTTPCookie(properties: [    .domain: "example.com",    .path: "/",    .name: "MyCookieName",    .value: "MyCookieValue",    .secure: "TRUE",    .expires: NSDate(timeIntervalSinceNow: 31556926)])! webView.configuration.websiteDataStore.httpCookieStore.setCookie(cookie)

Since you are pulling them over from HTTPCookeStorage, you can do this:

let cookies = HTTPCookieStorage.shared.cookies ?? []for cookie in cookies {    webView.configuration.websiteDataStore.httpCookieStore.setCookie(cookie)}

Old answer for iOS 10 and below

If you require your cookies to be set on the initial load request, you can set them on NSMutableURLRequest. Because cookies are just a specially formatted request header this can be achieved like so:

WKWebView * webView = /*set up your webView*/NSMutableURLRequest * request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"http://example.com/index.html"]];[request addValue:@"TeskCookieKey1=TeskCookieValue1;TeskCookieKey2=TeskCookieValue2;" forHTTPHeaderField:@"Cookie"];// use stringWithFormat: in the above line to inject your values programmatically[webView loadRequest:request];

If you require subsequent AJAX requests on the page to have their cookies set, this can be achieved by simply using WKUserScript to set the values programmatically via javascript at document start like so:

WKUserContentController* userContentController = WKUserContentController.new;WKUserScript * cookieScript = [[WKUserScript alloc]     initWithSource: @"document.cookie = 'TeskCookieKey1=TeskCookieValue1';document.cookie = 'TeskCookieKey2=TeskCookieValue2';"    injectionTime:WKUserScriptInjectionTimeAtDocumentStart forMainFrameOnly:NO];// again, use stringWithFormat: in the above line to inject your values programmatically[userContentController addUserScript:cookieScript];WKWebViewConfiguration* webViewConfig = WKWebViewConfiguration.new;webViewConfig.userContentController = userContentController;WKWebView * webView = [[WKWebView alloc] initWithFrame:CGRectMake(/*set your values*/) configuration:webViewConfig];

Combining these two techniques should give you enough tools to transfer cookie values from Native App Land to Web View Land. You can find more info on the cookie javascript API on Mozilla's page if you require some more advanced cookies.

Yeah, it sucks that Apple is not supporting many of the niceties of UIWebView. Not sure if they will ever support them, but hopefully they will get on this soon. Hope this helps!


After playing with this answer (which was fantastically helpful :) we've had to make a few changes:

  • We need web views to deal with multiple domains without leaking private cookie information between those domains
  • We need it to honour secure cookies
  • If the server changes a cookie value we want our app to know about it in NSHTTPCookieStorage
  • If the server changes a cookie value we don't want our scripts to reset it back to its original value when you follow a link / AJAX etc.

So we modified our code to be this;

Creating a request

NSMutableURLRequest *request = [originalRequest mutableCopy];NSString *validDomain = request.URL.host;const BOOL requestIsSecure = [request.URL.scheme isEqualToString:@"https"];NSMutableArray *array = [NSMutableArray array];for (NSHTTPCookie *cookie in [[NSHTTPCookieStorage sharedHTTPCookieStorage] cookies]) {    // Don't even bother with values containing a `'`    if ([cookie.name rangeOfString:@"'"].location != NSNotFound) {        NSLog(@"Skipping %@ because it contains a '", cookie.properties);        continue;    }    // Is the cookie for current domain?    if (![cookie.domain hasSuffix:validDomain]) {        NSLog(@"Skipping %@ (because not %@)", cookie.properties, validDomain);        continue;    }    // Are we secure only?    if (cookie.secure && !requestIsSecure) {        NSLog(@"Skipping %@ (because %@ not secure)", cookie.properties, request.URL.absoluteString);        continue;    }    NSString *value = [NSString stringWithFormat:@"%@=%@", cookie.name, cookie.value];    [array addObject:value];}NSString *header = [array componentsJoinedByString:@";"];[request setValue:header forHTTPHeaderField:@"Cookie"];// Now perform the request...

This makes sure that the first request has the correct cookies set, without sending any cookies from the shared storage that are for other domains, and without sending any secure cookies into an insecure request.

Dealing with further requests

We also need to make sure that other requests have the cookies set. This is done using a script that runs on document load which checks to see if there is a cookie set and if not, set it to the value in NSHTTPCookieStorage.

// Get the currently set cookie names in javascriptland[script appendString:@"var cookieNames = document.cookie.split('; ').map(function(cookie) { return cookie.split('=')[0] } );\n"];for (NSHTTPCookie *cookie in [[NSHTTPCookieStorage sharedHTTPCookieStorage] cookies]) {    // Skip cookies that will break our script    if ([cookie.value rangeOfString:@"'"].location != NSNotFound) {        continue;    }    // Create a line that appends this cookie to the web view's document's cookies    [script appendFormat:@"if (cookieNames.indexOf('%@') == -1) { document.cookie='%@'; };\n", cookie.name, cookie.wn_javascriptString];}WKUserContentController *userContentController = [[WKUserContentController alloc] init];WKUserScript *cookieInScript = [[WKUserScript alloc] initWithSource:script                                                      injectionTime:WKUserScriptInjectionTimeAtDocumentStart                                                   forMainFrameOnly:NO];[userContentController addUserScript:cookieInScript];

...

// Create a config out of that userContentController and specify it when we create our web view.WKWebViewConfiguration *config = [[WKWebViewConfiguration alloc] init];config.userContentController = userContentController;self.webView = [[WKWebView alloc] initWithFrame:webView.bounds configuration:config];

Dealing with cookie changes

We also need to deal with the server changing a cookie's value. This means adding another script to call back out of the web view we are creating to update our NSHTTPCookieStorage.

WKUserScript *cookieOutScript = [[WKUserScript alloc] initWithSource:@"window.webkit.messageHandlers.updateCookies.postMessage(document.cookie);"                                                       injectionTime:WKUserScriptInjectionTimeAtDocumentStart                                                    forMainFrameOnly:NO];[userContentController addUserScript:cookieOutScript];[userContentController addScriptMessageHandler:webView                                          name:@"updateCookies"];

and implementing the delegate method to update any cookies that have changed, making sure that we are only updating cookies from the current domain!

- (void)userContentController:(WKUserContentController *)userContentController didReceiveScriptMessage:(WKScriptMessage *)message {    NSArray<NSString *> *cookies = [message.body componentsSeparatedByString:@"; "];    for (NSString *cookie in cookies) {        // Get this cookie's name and value        NSArray<NSString *> *comps = [cookie componentsSeparatedByString:@"="];        if (comps.count < 2) {            continue;        }        // Get the cookie in shared storage with that name        NSHTTPCookie *localCookie = nil;        for (NSHTTPCookie *c in [[NSHTTPCookieStorage sharedHTTPCookieStorage] cookiesForURL:self.wk_webView.URL]) {            if ([c.name isEqualToString:comps[0]]) {                localCookie = c;                break;            }        }        // If there is a cookie with a stale value, update it now.        if (localCookie) {            NSMutableDictionary *props = [localCookie.properties mutableCopy];            props[NSHTTPCookieValue] = comps[1];            NSHTTPCookie *updatedCookie = [NSHTTPCookie cookieWithProperties:props];            [[NSHTTPCookieStorage sharedHTTPCookieStorage] setCookie:updatedCookie];        }    }}

This seems to fix our cookie problems without us having to deal with each place we use WKWebView differently. We can now just use this code as a helper to create our web views and it transparently updates NSHTTPCookieStorage for us.


EDIT: Turns out I used a private category on NSHTTPCookie - here's the code:

- (NSString *)wn_javascriptString {    NSString *string = [NSString stringWithFormat:@"%@=%@;domain=%@;path=%@",                        self.name,                        self.value,                        self.domain,                        self.path ?: @"/"];    if (self.secure) {        string = [string stringByAppendingString:@";secure=true"];    }    return string;}


The cookies must be set on the configuration before the WKWebView is created. Otherwise, even with WKHTTPCookieStore's setCookie completion handler, the cookies won't reliably be synced to the web view. This goes back to this line from the docs on WKWebViewConfiguration

@NSCopying var configuration: WKWebViewConfiguration { get }

That @NSCopying is somewhat of a deep copy. The implementation is beyond me, but the end result is that unless you set cookies before initializing the webview, you can't count on the cookies being there. This can complicate app architecture because initializing a view becomes an asynchronous process. You'll end up with something like this

extension WKWebViewConfiguration {    /// Async Factory method to acquire WKWebViewConfigurations packaged with system cookies    static func cookiesIncluded(completion: @escaping (WKWebViewConfiguration?) -> Void) {        let config = WKWebViewConfiguration()        guard let cookies = HTTPCookieStorage.shared.cookies else {            completion(config)            return        }        // Use nonPersistent() or default() depending on if you want cookies persisted to disk        // and shared between WKWebViews of the same app (default), or not persisted and not shared        // across WKWebViews in the same app.        let dataStore = WKWebsiteDataStore.nonPersistent()        let waitGroup = DispatchGroup()        for cookie in cookies {            waitGroup.enter()            dataStore.httpCookieStore.setCookie(cookie) { waitGroup.leave() }        }        waitGroup.notify(queue: DispatchQueue.main) {            config.websiteDataStore = dataStore            completion(config)        }    }}

and then to use it something like

override func loadView() {    view = UIView()    WKWebViewConfiguration.cookiesIncluded { [weak self] config in        let webView = WKWebView(frame: .zero, configuration: webConfiguration)        webView.load(request)        self.view = webView    }}

The above example defers view creation until the last possible moment, another solution would be to create the config or webview well in advance and handle the asynchronous nature before creation of a view controller.

A final note: once you create this webview, you have set it loose into the wild, you can't add more cookies without using methods described in this answer. You can however use the WKHTTPCookieStoreObserver api to at least observe changes happening to cookies. So if a session cookie gets updated in the webview, you can manually update the system's HTTPCookieStorage with this new cookie if desired.

For more on this, skip to 18:00 at this 2017 WWDC Session Custom Web Content Loading. At the beginning of this session, there is a deceptive code sample which omits the fact that the webview should be created in the completion handler.

cookieStore.setCookie(cookie!) {    webView.load(loggedInURLRequest)}

The live demo at 18:00 clarifies this.

Edit As of Mojave Beta 7 and iOS 12 Beta 7 at least, I'm seeing much more consistent behavior with cookies. The setCookie(_:) method even appears to allow setting cookies after the WKWebView has been created. I did find it important though, to not touch the processPool variable at all. The cookie setting functionality works best when no additional pools are created and when that property is left well alone. I think it's safe to say we were having issues due to some bugs in WebKit.