Sharing cookies between HTTP-Plugin, WKWebView and InAppBrowser

Hi, I’m trying to solve the following problem that I think is quite typical for many developers?

My app loads in main WebView (based on cordova-plugin-ionic-webview). It tries to make a call to server using this HTTP-Plugin as regular XHR would be blocked due to CORS restrictions.

When it gets Unauthorised response it will open up InAppBrowser (cordova-plugin-inappbrowser - WKWebView based as well) to show user login options (login must support ADFS redirects etc, so easy login via XHR/Basic is not an option here). I know the login will return proper cookies to InAppBrowser WebView - I can see them in Safari console. Cookies will be marked as secure/httpOnly.

After login the InAppBrowser is closed and the app will make another attempt to load data via HTTP-Plugin. Unfortunately something goes wrong here, as the session cookies are not accepted.

Also main WebView should be able to make plane GET requests, e.g. for image resources (non-xhr). Although, the main WebView will have different domain than InAppBrowser (“real” domain vs localhost app).

Should these cookies be theoretically shared between all these instances? Form Cordova-WkWebView docs: “This plugin creates a shared WKProcessPool which ensures the cookie sharing happens correctly across WKWebView instances. CDVWKProcessPoolFactory class can be used to obtain the shared WKProcessPool instance if app creates WKWebView outside of this plugin.”

Since WKWebView plugin implementation can use shared cookie storage for both main WebView and InAppBrowser, it should also be possible for HTTP-Plugin to access the same pool. As a result we could:

• Authenticate in InAppBrowser using whatever method is needed, including ADFS/SAML
• Access authentication cookies in main WebView for GET, non XHR requests
• Use HTTP-Plugin to make all XHR requests to bypass CORS restrictions imposed by WKWebView.

I’m not sure if this is the case for Ionic version as well? I have zero knowledge on iOS native development so that makes things a bit harder 😦 Similar approach (without HTTP plugin) worked just fine with UIWebView that did not restrict cookie or XHR/CORS.

I would greatly appreciate some feedback from anyone who managed to run that kind of scenario!

[ikosta]

@nooblado @maciej-zabielski @silkimen I just published the plugin cordova-plugin-cookies

[maciej-zabielski]

Some follow up on this - I know a similar question was answered in a discussion here. asked by @varunkumarm. @silkimen replied:

You can’t use this plugin to extract the cookies you’ve received in InAppBrowser, because it’s using an own web context which has nothing to do with this plugin.

[EDIT 05.11.2020] I have removed my original follow up as it was not entirely true, so I will spare the read and try to post our final solution afterwards. I believe we will eventually change the authentication method for mobile app so that it does not require server session and rememberMe cookies.

What I have found out until now (all XHR requests made with HTTP plugin):

1. After authentication (web page, not XHR) in WKWEbView (InAppBrowser) cookies are not available to XHR, but…
2. After reloading the browser app (not entire native app) the cookies get synced to underlying native cookie store and at this stage, XHR request will get the rememberMe cookie added automatically!
3. For the reason I do not understand, only rememberMe cookie (HttpOnly, Secure, with exp. date) is added automatically, but our session cookie is not (HttpOnly, Secure, Session exp).
4. Now the built in cookie management in HTTP plugin gets in a way, as it will store cookies received in it’s local storage and not the shared native store.
5. Having a session/cookie based authentication this creates a havoc, as we now have one session running in XHR and another one in WebView.
6. When we log out using InAppBrowser, of course its session is “logged out” but also the “DeleteMe” command will be executed and XHR will loose its “rememberMe” cookie. So this is another example where we can clearly see that they use common cookie store.

If only the session cookie would be added it would work pretty well. At the same time, if in further requests XHR would “restore” session based on rememberMe, it would have to make it available for the WebView do that requests made directly from there also get the proper session. I still don’t understand how WebView and XHR have one common cookie and one “individual” (session cookie). I would have to debug native code to see what cookies are available there at every stage.