cordova-plugin-ionic-webview

cordova-plugin-ionic-webview copied to clipboard

When installing a fresh build of my application and attempting to log in, it fails because the authentication cookie sent by the server is never stored. Closing the application and re-launching fixes the issue. There is an identical issue for cordova-plugin-wkwebview-engine here. Is this one of the issues that has been / will be fixed in this fork, or is there a viable workaround at this time?

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

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!

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.

This fork seems to have fix for this issue: https://github.com/agarcia17/cordova-plugin-wkwebview-engine It is behind the current master of the plugin though.

Yikes, that is one heavy handed fix.

@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 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.

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

+1 Still having this issue! Went back to UIWebView

+1 Is it something what is going to be fixed in this plugin pretty soon?

I uninstall WKWebView plugin then reinstall ios platform, so it working now.

This appears to be causing problems for me as well

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 ;) ...

I'm using in my app cordova-plugin-file-transfer to download/save files on device. In request there is no cookie header, even when app is not first opened on device. Looks like above solution with cordova-plugin-fetch solves that issue .. Maybe it will help someone to better investigate and solve that issue.

+1 mindf**k

edit: @mezykr your solution worked, thanks. I also found this https://github.com/psirenny/cordova-plugin-wkwebview-sync-cookies that I believe does the same thing under the hood.

What happened to the PR ? Did it work? Why was it not merged?

Has anyone found a fix for this issue that is not listed here? Is anyone from Ionic working on this at all?

+1 Would also love to see a working fix!

+1 Please fix this issue.

I've made a workaround for this so that the cookies work again after the first startup of the app. For that I created this plugin based on a different persons advice. If i find the Person again ill give him credit here and in the plugin of course:

https://github.com/COMLINE-AG/native-xhr-plugin/

This will make the use of cookies possible again.

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

@oliverjanik Well there is no real alternative for this until Ionic fixed this issue. I've tried many workarounds, but this workaround was the only one that worked.

If u have concerns about the 3 seconds of waiting, then make a request on application startup. If the user has to enter login data then the 3 seconds have passed already and the user will notice nothing about it.

Edit: I forgot to mention that u need to do this native request once. After this request and the wait of 3 seconds u can use normal xhr again.

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.

@asrytis do you use that to do all you ajax calls then?

Are there any news on this?

I think you need to get Apple to fix their Webview, to solve this, cleanly.

Any updates on this?

Can confirm otherwise that https://github.com/sortdinc/cordova-plugin-wkwebview-ionic-xhr suggested by @asrytis seems to do the trick in the meantime!

I can also confirm that the fork mentioned by @asrytis works with cookies on first app startup. However, there are issues playing media files, it seems there are still several major issues with the WK Webview that are not resolved https://issues.apache.org/jira/browse/CB-10141?jql=project%20%3D%20CB%20AND%20status%20%3D%20Open%20AND%20labels%20%3D%20wkwebview-known-issues

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

I have the same problem here. Cookies do not work the first time. If I kill and reopen the application, it works ...