breautek commented on issue #1533: URL: https://github.com/apache/cordova-android/issues/1533#issuecomment-1371603179
This is a two prong issue, both of which requires access/changes to the server. Firstly, the `hostname` preference is for your own app. It should not be the same as a server in which you may want to communicate to. Preferably should be kept to the default value of `localhost`. `"com.myapp.mobile.example-name-site"` should be fine as a value, if you want something different than `localhost`. This preference will change the browser's origin value, so once you pick a value, you should stick with it. Changing origin values means that you'll have different buckets for your local storage, which includes cookies, as they are bound to origins. Because you're migrating from cordova-android@8 to 10... as of cordova-android 10 we introduced something called a `WebViewAssetLoader`, which is what makes use of the `hostname` preference. The WebViewAssetLoader behaves somewhat like a proxy and makes it so your web app appear as if it's coming from an http(s) server, and changes your origin. So if you have an existing app, that means you will lose access to previously stored objects in your web storage containers. The data is still present on the device, but you do not have direct access to them via the web browser APIs. A migration plugin is necessary to use the `WebViewAssetLoader` and to bring over old data from existing installs. Cordova makes no attempt in migrating data for you. The purpose of the WebViewAssetLoader is to allow you to use browser features in which requires the document to be loaded from a secure context. A secure context means it must be loaded on an https protocol, which the WebViewAssetLoader emulates. However if you aren't ready for the data migration and you have important information stored in web storage, then you may opt out of this by using enabling `AndroidInsecureFileModeEnabled` preference. This will make cordova-android revert back to the filesystem strategy as used in cordova-android@9 and earlier versions. I would recommend making an action plan to migrate to the scheme approach to futureproof your app however. The `AndroidInsecureFileModeEnabled` is labelled as insecure because the underlying API that Google provides claims it's insecure. Therefore it's realistic to believe that that API option may become unavailable in the future. The android chrome webview I don't believe enforces CORS on `file://` based documents, but if it does, your `origin` value will be `null` and you'll need to add the appropriate response headers on your server APIs that your Cordova app hits. I've written an entire [blog post](https://breautek.com/articles/enabling-cors.html) on this (more in the context of WKWebview but the general information also applies to Chrome). I don't use Cookies in my apps, so I'm less familiar, but I know recent versions of chrome changed the cookie policy where it requires a secure context. This however shouldn't been changed by the cordova-android version, but rather the installed webview version on the device. Additionally the default SameSite policy was changed from `None` to `Lax` on Chrome as of version 90ish (i forget which version specifically). [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite) explains the `SameSite` cookie details, and it's not controllable by the client, but rather the server. I'm not sure how Chrome enforces cookies when it comes to file-based documents like what would have been used in cordova-android@8, but it's possible that you may require the `WebViewAssetLoader` stuff that was introduced in cordova-android@10. I do know on modern webview versions, when using WebViewAssetLoader, the server must set a `SameSite: None; Secure` when it sets cookies to allow the cookie to be set in a third-party context, which Cordova apps will always be considered third-party. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
