WkWebView Cookies on Initial Load

I am running into a super strange issue as I converted over from UIWebview. In our application, the user logs in and we set authentication cookies for our API server. This has always worked perfectly until we started using WkWebView for the newer iOS builds. I have tried trigger 2.8.4 and even 2.8.5. What is really wierd is I can get it to work great by killing or putting the app in the backgrond after install and then opening it again.

Here is a basic flow:

  1. Install App in iOS, App Opens after install
  2. User enters username and password and click login
  3. JSONP call is sent to API and response comes back. (In console I can see the set-cookie directives as expected)
  4. Cookies are evidently not set in the webview because subsequent calls to API do not include them in the request header
  5. User clicks HOME button to send app to background OR kills it completely
  6. User brings app back to foreground
  7. User logs in again
  8. JSONP call sent exactly the same as before
  9. Cookies are set correctly and all is well from that point forward.

This seems related to a few things I am seeing out there. Here is a good thread https://issues.apache.org/jira/browse/CB-12074

I wanted to see if anyone has produced a workaround for trigger.

Thank you for reporting this, especially the link to the Cordova issue!

This looks like a duplicate of:

We’re back from holiday so I’ll probably be digging into this next week.

Thank you @antoinevg. Let me know if you need anything else from me. It would be great to have a fix for our iOS users.

Can you please try it against:

"platform_version": "v2.8.5"


"browsersettings": {
    "version": "1.7",
    "config": {
        "accept_cookies": true

If it’s still failing, can you please attach the following:

  1. A small code snippet I can use to reproduce the issue on my side (you can email this to support@trigger.io if you’d rather not share publically)
  2. A copy of your app’s src/config.json file

We’ve finally managed to make some progress on this:

  1. Confirmed as a long-standing Apple bug that has been present in WKWebView since at least iOS 10.
  2. Existing workarounds did not work for JSONP calls.
  3. Existing workarounds for other calls were rendered ineffective after Apple stopped including cookies in response headers.
  4. We have found a workaround that does help in your particular instance.

Can you please try updating your platform to v2.8.6:

"platform_version": "v2.8.6"

…and, here’s the clever part:

When you app first starts up, use the new forge.tools.setCookie() API to set a dummy cookie for the domain(s) you are going to be making calls to.

For example:

    forge.tools.setCookie("trigger.io", "/api/v1/auth/hello", "foo", "bar", function () {
        // cookie has been set and cookie store has been synchronized
        // continue with normal startup, make JSONP calls etc.

This seems to “prime” the cookie store which then responds to the cookies sent by the server.

Only the first parameter, the domain, matters. You can set any value for the other parameters unless you wanted to provide a specific cookie.

It’s essential that you continue with your subsequent app startup in the completion callback as setting cookies and flushing the cookie storage is an asynchronous operation.

Finally, please note that this only works on hardware and NOT on the iOS simulator!

As a followup, the solution above is effective with one caveat. The DOM must be ready, or the forge.tools.setCookie will not fire in iOS.

So, if you want to “prime” iOS cookies the moment you load the app, you should wrap it in an event listener. ie.
document.addEventListener(“DOMContentLoaded”, function(event) { //DOM Loaded
forge.tools.setCookie(YOURHOSTNAME, “/”, “foo”,“bar”);

Thanks a million @ antoinevg

1 Like