GitHub user breautek added a comment to the discussion: Does allow list requires importing cordova.js to work correctly?
> I'm still a bit confused, so it's incorrect that setting the content prop in > the xml config to an extenal site? Yes. Setting `content` to an external site will work to a degree but Cordova isn't designed to operate this way, and the Google Play store / iOS App Store has policies in place regarding how remote web content should interact with native device APIs which you will most certainly break if you intend to deploy through those distribution channels. Just speaking about web apps in general, Google & Apple allows remote web content loaded in their webviews, but they should not access native device APIs. On a more functional note, Cordova offers a [development tool](https://github.com/apache/cordova-serve) to serve the platform web content over a webserver, which you can set the `content` src appropriately to make use of this development tool. This allows you to update the www assets without repacking/rebuilding the binary for faster development iterations. So there are valid reasons why you'd point `content` to a remote server, but for production release the `content` should be pointing to locally bundled assets. > And, in theory, if I move all the plu-in js files and cordova.js to the > extenal site folder, will the allow list should works properly? Or the list > only works if the site stores inside the www folder? In theory yes, if you copy the platform www assets and load them with your external site, it probably will work technically. But you're also opening yourself to RCE and breaking the aforementioned app store agreements. And the platform www assets are platform-specific, so you also won't be able to support multiple platforms (e.g. iOS and Android). Even if your site is completely secure and does nothing malicious itself, the fact that the mobile application loads content remotely opens the possibility for MITM ([Man-in-the-Middle](https://en.wikipedia.org/wiki/Man-in-the-middle_attack)) attacks, where if your app is launched in a malicious network, `yourserver.com` might not be actually `yourserver.com` and point to a malicious host instead, and then use native device APIs installed/exposed by your app can be used to pull information on your user for malicious intent. So I cannot stress enough that the web application should be bundled with the native binary. The native binary should not download anything that can be remotely executed. It's fine for the native binary to download supporting assets like data files, images, etc, but not code. GitHub link: https://github.com/apache/cordova/discussions/512#discussioncomment-11375493 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
