[GitHub] [cordova-docs] breautek commented on issue #1022: Document warnings on using remote source for

[GitBox <gi...@apache.org>]

breautek commented on issue #1022: Document warnings on using remote source for <content>
URL: https://github.com/apache/cordova-docs/issues/1022#issuecomment-546079284
 
 
   > As long as third-party software doesn't touch it, it should be fine.
   
   If it is exposed, it's already a problem (and a security vulnerability)
   
   > And they can't just mean all third party software.... That would mean no jQuery (remote or local).
   
   In this context, I believe third-party software just simply means remote software. if jQuery is bundled with the app, then I believe it's okay.
   
   > Is it correct to say Cordova uses extended capabilities provided by the standard webview? Does that count as safari modifications? If so, I would say that is the end of Cordova.
   
   Cordova provides this functionality via `cordova.js` and the cordova bridge that allows javascript to send messages to the native environment, which in then turns into native API calls.
   
   > Cordova does not support injecting native code into the app (as far as I am aware.)
   Cordova's codebase itself does not inject native code, though technically speaking a plugin could offer that can feature, however that isn't really Cordova's concern. Cordova does give native access to javascript via the cordova bridge, and the bigger problem is accessing these APIs using remote sources.
   
   > (PS. Why do you think this kind of usage is improper? I think it has incredible potential. Eg. write one website that works for desktop and apps. Great for teams low on man power.)
   
   You can still do this without relying on a remote sources. You simply bundle your sources with your cordova app. This however does require some thought and planning on how to architect your product(s) so that code can be shared between two apps.
   
   Generally speaking, if you bundle your sources with your app then you're fine. These policies I'm sure are mostly to keep your app secure. An insecure app hurts both you as the developer, and the app provider (because people will blame Apple/Google for allowing your insecure app). Additionally, Apple who wants to review every single app update you publish, they don't like mechanisms where your app can significantly change in behaviour and bypass their review process. Hence the policy "code distribution isn’t the main purpose of the app".
   
   Loading remote content still has their uses. Webpack hot reload server for example, which is useful for development. Enterprise users can build iOS apps that don't get distributed via the apple store so they don't have to obey apples policies is another reason why it's okay to keep the functionality. It's just something users should be aware of if they intend to submit their cordova app to the app stores.

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cordova.apache.org
For additional commands, e-mail: commits-help@cordova.apache.org