Cookies aren't sent to iframes or inappbrowser windows that load from the same domain

[adamdport]

Describe the bug
Cookies aren't sent to iframes or inappbrowser windows that load from the same domain

To Reproduce

1. Make a request through this plugin that has a response that sets a cookie.
2. Load an iframe or inappbrowser window from the same domain as the above request
3. Observe no cookies are sent

Expected behavior
iframes and inappbrowser windows have access to cookies set by cordova requests to that domain

[NiklasMerz]

The InAppBrowser issues should be fixed with this PR: apache/cordova-plugin-inappbrowser#825

Not sure about iFrames thoug.

[adamdport]

What should the URL be? If I try to use convertProxyUrl, it uses the scheme/hostname (eg. app://localhost/_http_proxy_mydomain.com/whatever)) and results in an "unsupported URL" error in inAppBrowser. Without the convertProxyUrl I can hit my remote but I don't get the cookies. I've tried both with and without the usewkwebview=true from the docs. I'm not sure how to proceed.

[NiklasMerz]

The proxy won't work in the InAppBrowser. If you call an URL with the proxy in the main webview the cookies should be synced to the inappbrowser. Same for the opposite. Cookies set in the InAppBrowser should work in the proxy.

But as I said in the previous comment I discovered an issue that came in when WKWebView got integrated in cordova-ios. The cookie sync currently does not work. I opened two Pull Requests, one in cordova-ios and one in IAB. When these are merged this should work again.

apache/cordova-plugin-inappbrowser#825
apache/cordova-ios#1031

You can use these branches in our forks until the PRs get merged and a new version is released:

cordova platform add https://github.com/GEDYSIntraWare/cordova-ios#patched
cordova plugin add https://github.com/GEDYSIntraWare/cordova-plugin-inappbrowser#patched

[adamdport]

Thanks for the reminder. I checked and had the branches that you've currently got in pull request, ie. cordova-ios#schemehandler-hook and cordova-plugin-inappbrowser#processpool. I switched to #patched for both and don't see any difference. I'm still getting the "unauthorized" message my remote would return if the authentication cookie was missing. I'm not sure what else to try?

[girish2711]

@adamdport yes, I am also on the same boat. I did follow @NiklasMerz suggestion, but still I am not able get cookies on Cordova webview. All XHR calls work fine, but SSO calls and iFrame attaching failed. It looks like embedding 3rd party domain contents to iFrame is blocked due to newly introduced web security. But not sure about cookies

[NiklasMerz]

More comments: apache/cordova-ios#1030 (comment)

Bringing comments added for #1004

@NiklasMerz Thanks for the WKURLSchemeHandler implementation. I took #1030 PR and integrated with your plugin https://github.com/GEDYSIntraWare/cordova-plugin-webview-proxy. Also changed the URL per your suggestion. All my XHR calls are now directed to webiewproxy.m and completes with proper response.

However, in my case my API responds with a few session cookies and I don't see them getting synced to my Cordova main web view. I see cookies in native cookie store but not in Cordova main web view. Is this expected ? Any solution to this?

I have a Single Sign On implementation which needs these session cookies to be sent along with http GET URL request (window.location = url to a subdomain) to a my own server. But the request is sent without cookies and hence it fails.

I tried by configuring CDVWebViewEngine's webdatastore to a nonPersistant one and added cookies to the same store as in below, but that didn't sync cookie to Cordova Main webview

first added app bound domain in the info.plist

and then in CDWebViewEngine:77.

if (@available(iOS 14.0, *)) {

configuration.limitsNavigationsToAppBoundDomains = YES;
WKWebsiteDataStore *dStore =[[CDVWebViewProcessPoolFactory sharedFactory] sharedDataStore]; // by adding new method in sharedFactory

configuration.websiteDataStore = dStore;

} else {
// Fallback on earlier versions
}
and in webviewproxy.m:40

WKWebsiteDataStore* dataStore = [[CDVWebViewProcessPoolFactory sharedFactory] sharedDataStore];
WKHTTPCookieStore* cookieStore = dataStore.httpCookieStore;
Any idea if cookies are not meant for syncing or am I missing something ? I am testing in iOS14 with XCode 12.3.

[NiklasMerz]

Seems like the current implementation works only for HTTP requests properly and we still have issues with certain cases like IFrames etc?

[mattdsteele]

@NiklasMerz I'm continuing to see issues with cookies not being shared between the Cordova app, and the InAppBrowser.

My environment:

• [email protected]
• [email protected]
• [email protected]
• [email protected]

On deviceready, my application launches an inappbrowser to https://example.com/login. In the browser, the user enters their credentials, submits a form, and the server responds by setting a cookie on the example.com domain; and then closes the browser window.

Later, in the Cordova app, I call fetch(window.WebviewProxy.convertProxyUrl('https://example.com/service')); but the server rejects it as missing its authentication cookie. I do not see any cookies being sent in the Network tab using Safari's dev tools.

[mattdsteele]

A few interesting things I've found while testing (now that I've set a custom scheme):

After getting an auth cookie in an InAppBrowser window, I see the following in the Cordova app:

• fetch(convertProxyUrl(url), { credentials: 'include' }) fails with Cookies not being sent
• new XMLHttpRequest().open(convertProxyUrl(url)) fails with Cookies not being sent
• <img src="convertProxyUrl(url)"> fails with Cookies not being sent
• <img src="url"> succeeds, surprisingly!

[NiklasMerz]

Does it work the opposite way if you get the cookie in the Cordova window and use it in the InAppBrowser window? That's how we are doing it.

[mattdsteele]

Briefly testing this, I wasn't able to get the opposite way to work.

I acquired a cookie in the Cordova window using fetch(convertProxyUrl(authServiceUrl))), then tried to open a secured site using the InAppBrowser window, and did not see any cookies sent.

That said, I suspect I might have something setup wrong, because I also tried to open the secured URL in the Cordova window (using fetch(convertProxyUrl(securedUrl)) and also did not see cookies being sent. So if anyone else is able to test or confirm whether it's working for their app, that might be better.

[knoppanthony]

First off, Thank you for all the hard work and effort you've put towards this issue @NiklasMerz

We've recently updated our Cordova app to use the following:
[email protected]
[email protected]
[email protected]

We're seeing the same issue remaining that @mattdsteele and @adamdport have mentioned.

In our app, we obtain a cookie as part of the main application's WkWebView and then open an inappbrowser instance. That cookie appears to no longer transfer over to the inappbrowsers WkWebView . If we keep everything as UIWebViews, we're fine.

[adamdport]

@knoppanthony FWIW I ended up not needing this plugin. I was able to get my app working with WkWebView using AppBoundDomains as per my comment here. If you only need to authenticate with one domain, you probably don't need this plugin. Theoretically you should be able to authenticate with up to 10 without this plugin, but personally I could only get one to work.

[girish2711]

In fact I ended up matching the hostname to my domain name. App dropped syncing cookies when my origin was something like "myscheme://myapp" while my domain name was "mydomain.com". However when I change "hostname" in config.xml to match my domain name, origin became "myscheme://mydomain.com". Cookies will sync properly with this change. It is strange that apple doesn't care schema !. All cookies from subdomain too started syncing properly.

Unless if you have a scenario of connecting to multiple domain names (not subdomains) then you may need this plugin + new way of native XHR calling that @NiklasMerz gave.

[menelike]

While I could not fix Iframes, with #15 I have no issues regarding the InAppBrowser. Can anyone confirm this?

[NiklasMerz]

Please check out #18 for a possible fix

[mattdsteele]

#18 worked for me!