I might be missing something obvious here, and if so, I apologize in advance.
I expected this to work:
<div v-show="!metadata">
But it didn't. Is there a good reason for this?
Not sure what your setup is - but it should work. Here's an example: http://jsfiddle.net/yyx990803/Rjk3x/
Figured out the source of the problem. When I do !metadata, this does new Function(exp) which violates the Content Security Policy of the Chrome app I'm using this in. The exact error printed to the console is this:
Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "default-src 'self' chrome-extension-resource:". Note that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.
Invalid expression: !metadata
AngularJS added a ngCsp directive to support apps, extensions, and websites with CSP enabled. And I believe that it's now the default. Thoughts on supporting something like this?
I see. I think this probably will be implemented as an optional plugin, although I'm not sure if I have time for it any time soon. If you could edit the title to be CSP specific I can keep it open for further discussion. Thanks.
For now, you should be able to enable unsafe-eval in your extension via manifest.json. If you don't have script-src present, it defaults to the original secure settings.
Granted that enabling such a thing is not recommended, but it'll get you running until a solution is cemented.
Chrome Apps are not allowed to relax the CSP. From Google's docs:
Chrome extensions will let you relax the default Content Security Policy; Chrome Apps won’t.
@feross Cripes, I thought he was doing an extension. Good shout.
One option seems to be to avoid using anything but the simplest expressions which can be parsed, it seems, without the use of new Function, but that's unfortunate.
I think CSP support will take quite some time to land. In the meanwhile if you really want to use Vue in a Chrome app, could a sandboxed architecture work for you? i.e. running a Vue interface in the front and communicate with it via message passing: http://developer.chrome.com/apps/app_external.html#sandboxing
The sandbox approach could work, but I'm not keen on adding that additional complexity (i.e. turning all sync function calls / property accesses into async ones). It's unfortunate that chrome apps are so restrictive and don't allow loosening the CSP. In the meantime, I'm going to just use EventEmitter and hook the events to the DOM manually for webtorrent. I don't think it will be too bad, though when CSP support lands I'll take another look at using vue.js. Thanks!
Pre-compiling would be another way to approach this. See:
good find feross!
@feross unfortunately, new Function() is essential in Vue's current implementation for data binding, which is very different from how Handlebars uses it. Also because Vue doesn't return a static rendered string, but maintains a live DOM node, there's really no way to pre-compile Vue templates.
Closing for now because implementing a CSP-compliant expression parser would significantly bloat the code base for a marginal use case. On hindsight, it is possible to avoid using expressions all together by using only computed properties...
This is a significant blocker for us using vue.js in a privileged environment on FirefoxOS apps – we have a sandbox workaround, but still really sucks :(
Personally I'd love to see CSP-compliance implemented here, I am guessing this will be a blocker on more and more projects
@k88hudson I had the same use-case. You can package Vue manually with a JavaScript parser and all that's needed is modifying a couple places Vue uses string-to-function conversion.
It's not the prettiest implementation, but you can check it out here: https://github.com/cecchi/vue/commit/d1caa5253069aeae2a66cc5578afe05903523d84
@cecchi thanks, awesome!
@yyx990803 any chance you'd consider merging an implementation using notevil?
@k88hudson it will most likely be a separate build, since a CSP compliant interpreter can add some bulky code which is not needed in other situations. But yeah, that's definitely on the roadmap, I've just been waiting to finish the 0.11 refactor first.
@k88hudson https://github.com/yyx990803/vue/tree/csp
I meet this same problem in [email protected]. I solved it just add the page to sandbox option in manifest.json.
{
"manifest_version": 2,
"name": "my-tab",
"version": "1.0",
"chrome_url_overrides": {
"newtab": "index.html"
},
"sandbox": {
"pages": ["index.html"]
}
}
Thanks to @luxp .
This way does not work for me:
popup.html
<meta http-equiv="Content-Security-Policy" content="script-src 'self' 'unsafe-eval' 'unsafe-inline' ">
But your way dit work for me, saving my time! Thanks a lot.
part of manifest.json:
{
"manifest_version": 2,
"browser_action" : {
"default_popup" : "popup.html",
"default_icon" : "gitlab.png"
},
"sandbox": {
"pages": ["popup.html"]
}
}
Most helpful comment
This is a significant blocker for us using vue.js in a privileged environment on FirefoxOS apps – we have a sandbox workaround, but still really sucks :(
Personally I'd love to see CSP-compliance implemented here, I am guessing this will be a blocker on more and more projects