cordova-plugin-ionic-webview: Cookies Ignored on First Application Execution

I was struggling with this issue for some time now. Gladly I’ve come up to a working solution with ver 4.0.0 of Ionic plugin for iOS11+. Ironically all fix is done in config.xml file itself: <preference name="Hostname" value="marek-rulez.com" />

So no need to setting cookies manually in native wrapper. For me setting the domain solved the issue. Hope it will help someone.

Thank you very much @marecektn For those who are on capacitor: Just change/add this to capacitor.config.json:

  "server": {
    "hostname": "yourdomain.com"
  }

It will change your ionic address to capacitor://yourdomain.com and cookies are passing correctly

It would be extremely helpful if this issue was at least referenced in the https://ionicframework.com/docs/wkwebview/ page. This is a pretty major limitation to WKWebView and debugging the issue is not intuitive.

I have the same issue, cookies not working the first time.

ionic 3.20.0 - solution - https://github.com/CWBudde/cordova-plugin-wkwebview-inject-cookie

npm i cordova-plugin-wkwebview-inject-cookie
ionic cordova plugin add cordova-plugin-wkwebview-inject-cookie

in app.components.ts :

declare var wkWebView: any;

...

    document.addEventListener('deviceready', () => {
      wkWebView.injectCookie('https://domain.com/');
    });

Based on the mentioned workaround in my previous post, I have developed an additional plugin that allows to inject a dummy cookie to get the sync process started properly. While this will only work in iOS11 (and above) it solves the issue sufficiently for my client. The repo can be found here: https://github.com/CWBudde/cordova-plugin-wkwebview-inject-cookie

I also seem to be experiencing this issue, but for me the cookies don’t ever seem to be sent or stored even when I restart the application (using a simulator). I can see Set-Cookie is being sent back properly, and this all works fine in UIWebView, but for WKWebView the cookies never seem to be stored at all.

Same issue here. I don’t think there is a solution in this fork. This is really a blocker for us in user experience. Please take a look at this!

@l3ender I am not aware of any documentation about this. I’ve just realised it during debugging. The github page says that Default value is localhost. Based on this knowledge you can assume, that safari syncs cookies based on domain name, therefore localhost != your-domain

Trial & error. That’s why I commented on this post since it is really time consuming to find.

I guess you have tried my solution (which works at least acceptable for the company I work for). It’sa problem that it only works with iOS 11, but beyond this it should work fine. If it doesn’t, please fill a bug report so that I can adress the problem.

Based on that plugin it would be possible to fix the issue in the ionic plugin, but it would require to intercept all XHRs and look for the domain just to inject a cookie for the very first access (to that domain). This will solve the issue for iOS 11, but might also slow down the performance (slightly) for all requests.

I tried most of the wkwebview xhr workarounds and went with this one: https://github.com/sortdinc/cordova-plugin-wkwebview-ionic-xhr

The plugin caches cookies at the native layer between requests but it does not attempt to sync cookies between the WKWebView and the native sessions. From the JavaScript context, this means “document.cookie” won’t contain any cookies returned from XHR handled at the native layer and the native iOS XHR will not see any cookies returned from remote resources fetched by the browser context, such as images.

This also causes websockets to break on many apps that rely on sticky session cookies to connect to the same server. Even if you were to use localstorage for auth, it’s hard to get around the sticky session issue.

When you will call first the same request using cordova-plugin-fetch, it will “unlock” saving set-cookie header in next normal request. That fixes issue when app is opened first time after installation. But it’s not so elegant solution 😉 …

Thank you very much @marecektn ! This solved the problem for me. My hostname was something like: ionic://domain and I changed it to ionic://domain.net

and now it works. The API sending the cookie is on api.staging.domain.net

+1. Because of the cookie issue, I had to uninstall the WKWebView plugin. Any solutions?

Here you write: “We wanted to make sure that people could easily switch to WKWebView without many issues, but there are still some things that you’ll need to consider.” Why isn’t it solved already??? This is already noticed in 2014

@mukana-lahtelat I don’t think this fixes XHR requests, it seems to only deal with the loadRequest lifecycle, meaning on raw page loads it will re-inject the cookies. The better fix for non-XHR requests is outlined here.

I was struggling with this issue for some time now. Gladly I’ve come up to a working solution with ver 4.0.0 of Ionic plugin for iOS11+. Ironically all fix is done in config.xml file itself: <preference name="Hostname" value="marek-rulez.com" />

So no need to setting cookies manually in native wrapper. For me setting the domain solved the issue. Hope it will help someone.

If there are multiple domain…

Thank you very much @marecektn For those who are on capacitor: Just change/add this to capacitor.config.json:

  "server": {
    "hostname": "yourdomain.com"
  }

It will change your ionic address to capacitor://yourdomain.com and cookies are passing correctly

Works on ios and doesn’t work on android. If “hostname” in config the same as external API hostname it does local request.

I spent the better part of 2 days on this issue, the fix by @CWBudde works for me for iOS 11, but I still need to support iOS 10. The cookie sync plugins did not work for me, maybe because my cookies all originate from xhr, or maybe because issues wrt the process pool that leaves cookies out of reach from each other(?).

But there is good news: finally I settled on this plugin by Oracle: https://github.com/oracle/cordova-plugin-wkwebview-file-xhr It replaces the entire XMLHTTPRequest object and tunnels all xhr to native calls, thereby bypassing CORS restrictions (the goal of that plugin) but also the session cookies are now stored and transmitted correctly. I tested on iOS 10+ and that works 😃

Also I should say I can not use the Ionic webview plugin, I use the cordova wkwebview plugin. I realise that there is already a similar plugin for the Ionic webview, but I thought there could be other people with same issue that use cordova wkwebview.

This is still a large issue, anything we can do about it? With XHR requests, we use bearer auth that we set up manually, but for requests made by the browser, like through img tags, there’s literally no workaround for this. Authenticated images just don’t load the first time users use our app and there’s nothing we can do about it.

EDIT from the future: For those looking to implement the solution @asrytis mentions below, you should use XMLHttpRequest’s responseType = "blob"; feature to download the image and URL.createObjectUrl to save the data.

More info at this incredibly useful blog post and on MDN

So do a native request and wait 3 seconds? Really?