-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CSP unsafe-inline required to use? #616
Comments
The devtools can't communicate with the webpage without injecting a script. |
Does it have to be inline? Can you reference a |
There's at least one extension developer who's gotten around CSP. This was a hard error to figure out for me, and disabling CSP locally isn't really ideal either. I haven't looked at how the extension communicates with Vue yet, but there might be a way... |
Been playing around a bit with this and I've found a few ways to get the dev tools working with CSP enabled. The first two solutions require changes to
Would a PR for 1 and 2 be accepted? |
Hey @chearon! Appreciate you taking the time to look into this.
Admittedly this is a creative solution, but I wouldn't say it's the nicest fix I've ever seen 😉
This isn't a bad approach. My only worry would be people leaving this on in production (and then it becomes a neat way for you to bypass CSP for your XSS payload!) -let's be honest, at least one person would probably do this so it feels too much like giving developers a shotgun to blow their own feet off with.
Interesting, and it seems like in Chrome the extensions aren't impacted by CSP either (which is in-line with how I'd expect extensions to be treated by the browser). This could be a nice workaround for Firefox.
Honestly, I don't understand why this wasn't the approach taken from the beginning: two separate builds, one dev build with the dev tools initialization code in and one prod build without it. Am I missing something obvious which would have prevented this from working? Why is injecting scripts into the page preferable? I'm pretty sure React took the same approach and I really don't understand why. I can't see that this would cause problems if the dev tools weren't there, it'd just be a message sent into the aether. |
I think the post I linked to was solving something a little different actually.
Yep. So this issue is entirely a Firefox compatibility thing (see #621 which fixes it, I've been using it).
I dunno, maybe a Vue team member can answer that. It does seem cleaner to have the initialize code inside a dev build; it wouldn't have to detect Vue by checking every element after X seconds. All browsers do support content scripts behind CSP in one way or another though. |
I think this is to support |
Hey, as I wrote in #621 I don't think we can go around I see two possible solutions:
|
Why can't there be two separate builds, or a separate script we include on the page which contains the hook (which then won't trip CSP)? |
So apart from installing plugin you would like to attach another script and also make sure whether those versions are compatible? I guess not :D What might solve your problem is remote so this is the 3rd solution ☝️ |
I hadn't tried that, @michalsnik - but it's an interesting solution. Presumably I'd only need to add |
Over here I mentioned that extensions don't violate CSP and that dev environment headers are kinda risky.
I also went down this route but if I understand right, we have to update the hash any time you guys make changes to those files right?
I'm glad there's several options, but all of them involve us doing something or changing the application in a way to make the extension work. That's kind of a bummer considering Chrome users don't have to do anything :( |
I am actually getting a CSP error in Chrome as well, not for the script but for the inline styles needed for the hilighting components in the DOM. Chrome will also not allow the inline style even if the has is added to style-src header. 😢
I don't think this is easily addressed until CSP 3.0 establishes a mechanism for allowing it and the best solution I can see is to add a setting to the extension that would simply disable the feature so my console log isn't getting spammed with CSP errors. |
In firefox I'm now getting: |
https://bugzilla.mozilla.org/show_bug.cgi?id=1267027 is the relevant upstream bug. I've read it, but I'm not sure if there is content that is useful, or specifically what changed in Firefox 58. In particular they point to the 'contentScripts' API as a workaround. |
You're right, when I take off Too bad for Firefox. It's pretty clear they're doing it wrong. Someone on that bugzilla issue said the react/redux devtools have the same problem, which is probably just causing more devs to switch to Chrome.
|
Is it correct that Vue doesn't work with CSPs which don't allow That's a pity for Electron developers where we are warned about NOT allowing |
@cawoodm I have the exact same problem. Did you find a solution? |
I just found a working solution: new Vue({
el: '#app',
store,
router,
i18n,
render: function(createElement) {
return createElement(App);
},
components: {
App
}, https://www.codementor.io/vuejsdevelopers/why-you-should-avoid-vue-js-dom-templates-c4chvgjlh |
It seems this is still an issue, preventing any apps with reasonable CSPs from using vue-devtools in Firefox. Has anyone found a workaround, or have an idea about how to update this add-on to fix that? |
I have the same problem as in thelounge/thelounge#3897, I get
|
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Version
4.1.3
Browser and OS info
Firefox 59.0b8
Steps to reproduce
Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src”). Source: ;(function(e){let t={};if(e.hasOwnProper....
Page:1
Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src”). Source: ;(function(e){setTimeout(()=>{const n=do....
Page:1
Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src”). Source: ;(function(e){let n=null,t=0;const o={no....
Page:1
unsafe-inline
What is expected?
What is actually happening?
The text was updated successfully, but these errors were encountered: