executing javascript directly in the webview is deprecated

[shankari]

e.g. https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/CordovaWebView.java#L92

    /**
     * Send JavaScript statement back to JavaScript.
     *
     * Deprecated (https://issues.apache.org/jira/browse/CB-6851)
     * Instead of executing snippets of JS, you should use the exec bridge
     * to create a Java->JS communication channel.
     * To do this:
     * 1. Within plugin.xml (to have your JS run before deviceready):
     *    <js-module><runs/></js-module>
     * 2. Within your .js (call exec on start-up):
     *    require('cordova/channel').onCordovaReady.subscribe(function() {
     *      require('cordova/exec')(win, null, 'Plugin', 'method', []);
     *      function win(message) {
     *        ... process message from java here ...
     *      }
     *    });
     * 3. Within your .java:
     *    PluginResult dataResult = new PluginResult(PluginResult.Status.OK, CODE);
     *    dataResult.setKeepCallback(true);
     *    savedCallbackContext.sendPluginResult(dataResult);
     */

Note also that executing javascript directly requires specifying 'unsafe-eval' in the Content-Security-Policy.

[bsorrentino]

Hi, thanks for feedback

I'll provide fix as soon as possible

[bsorrentino]

fixed provided in version 2.0.6

[shankari]

The fix in https://github.com/bsorrentino/cordova-broadcaster/commit/f8ded25897c54aa44b7abc69b88f048366dcaf75 doesn't seem to have worked. I will open a new issue.

12-02 08:56:27.650  22195-22195/edu.berkeley.eecs.emission I/chromium﹕ [INFO:CONSOLE(1070)] "Uncaught (in promise) EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' 'unsafe-inline' https://berkeley.qualtrics.com https://jfe-cdn.qualtrics.com".

[bsorrentino]

Hi thanks for feedback

Probably it is related to origin access and solution could be found here

[bsorrentino]

Try this declarations in your index.html

Content Security Policy

Controls which network requests (images, XHRs, etc) are allowed to be made (via webview directly).

On Android and iOS, the network request whitelist is not able to filter all types of requests (e.g. <video> & WebSockets are not blocked). So, in addition to the whitelist, you should use a Content Security Policy <meta> tag on all of your pages.

On Android, support for CSP within the system webview starts with KitKat (but is available on all versions using Crosswalk WebView).

Here are some example CSP declarations for your .html pages:

<!-- Good default declaration:
    * gap: is required only on iOS (when using UIWebView) and is needed for JS->native communication
    * https://ssl.gstatic.com is required only on Android and is needed for TalkBack to function properly
    * Disables use of eval() and inline scripts in order to mitigate risk of XSS vulnerabilities. To change this:
        * Enable inline JS: add 'unsafe-inline' to default-src
        * Enable eval(): add 'unsafe-eval' to default-src
-->
<meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com; style-src 'self' 'unsafe-inline'; media-src *">

<!-- Allow requests to foo.com -->
<meta http-equiv="Content-Security-Policy" content="default-src 'self' foo.com">

<!-- Enable all requests, inline styles, and eval() -->
<meta http-equiv="Content-Security-Policy" content="default-src *; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval'">

<!-- Allow XHRs via https only -->
<meta http-equiv="Content-Security-Policy" content="default-src 'self' https:">

<!-- Allow iframe to https://cordova.apache.org/ -->
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; frame-src 'self' https://cordova.apache.org">

[shankari]

Yes, I can confirm that, as I had commented in https://github.com/bsorrentino/cordova-broadcaster/issues/5#issue-137982201, specifying 'unsafe_eval' in the CSP works. But that doesn't change the fact that sendJavascript is deprecated as described in the comment above. It was deprecated in 2014 and I am not not sure when it will be removed.

We should switch to the bridge instead...

[shankari]

Hm on the other hand, from http://markmail.org/thread/lasyzbmq2bckkga6, Andrew Grieve, May 26, 2014 6:34:37 pm

Might be one of those leave it @Deprecated forever kind of things.