Spurious error in firefox when used with stripe.js

[jaredwindover]

I'm seeing the following error in firefox in the console when I have redux devtools enabled on a page that's including https://js.stripe.com/v3/, which comes with a fairly comprehensive Content Security Policy.

Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src https://js.stripe.com”). Source: !function(t){function __webpack_require_....

Everything seems to still be working, but it took me a while to track down what the actual interaction was. At least a clearer error when a resource's CSP is incompatible with redux devtools would be really helpful.

[fred-stripe]

Just going to chime in here: I believe that this issue is because the iframe that Stripe.js uses for communications has a CSP that forbids self and unsafe-inline. Using redux-devtools in Chrome I don't get any errors, so it seems the Firefox extension is doing something different here; injecting a script maybe?

[fred-stripe]

Oh, I forgot to add! You can easily test this by visiting this page in Firefox with the extension enabled:

https://stripe.com/docs/elements/

[clarkbw]

Looking to @digitarald for this :)

[digitarald]

Maybe the CSP rules in extension and the site somehow clash. I filed an issue on the Firefox side: https://bugzilla.mozilla.org/show_bug.cgi?id=1400924

[digitarald]

Looks like this is a long standing bug with Firefox being too strict with CSP and applying the rules as well on scripts injected by extensions & bookmarklets.

[archae0pteryx]

Is there any sort of resolution here?

[tommym9]

Bump

[digitarald]

Re-bumped the security team to give some input, so far the bug did not get traction.

[luskin]

Same on both firefox and chrome

[devinceble]

Also have this error +1

[jag1989]

+1, Also have this with the LastPass extension

[morfie78]

+1

[manis404]

+1

[raymondTheDev]

Any update regarding this issue?

[digitarald]

Work is happening to make CSP work smarter for injected scripts. The bug is assigned and has patches but seems to be moving slowly. I will check in with the team to find out where this sits in their backlog.

[belonog]

Also have this error +1

[zalmoxisus]

I see the limitation is only for injecting from content script, but it's allowed to inject it from devtools panel script. The problem is that we need it to be done before the page is loaded, so we'll need to reload the page (probably adding a button for this case):

chrome.devtools.inspectedWindow.reload({ injectedScript: 'our page script here' })

I'll bring it to 3.0 version of the extension, since it would require a polling mechanism instead of the current messaging system.

[digitarald]

Just as an update from the Firefox side: The patch has a lot of traction lately and is being actively worked on, but I can't make any promises on a Firefox version yet as its a complicated problem space.

[zalmoxisus]

Thanks for keeping us updated!

I think this issue is not quite critical for our extension, it is mainly meant for development environment. It's nice to use it also in production to see the current state in case of any troubles, but one could just export lifted state (store.liftedStore.getState() in case of including instrumentation) or history of actions (redux-remotedev does that) from there and import in development environment with more tools and less limitations, the extension will recompute the exact state.

[pr0con]

Still going strong in 2019

[elgin9507]

I have the same problem in Firefox browser. But, despite this error, everything is working fine.

[web-surfer]

Still an issue on Firefox.

[iumyidol]

and its still an issue today

[markerikson]

Folks, nothing has changed with this. You don't need to keep adding comments saying "still an issue".

If there is an actual potential technical solution, the best thing you can do would be to file a PR that implements it. (It's also possible this is fixed in the upcoming DevTools Extension 3.0 version, which is currently in beta - it would help if someone could try it out and actually report on whether that might fix the problem.)

But otherwise, just adding a "still broken" comment is not helpful.

[chrisbward]

Fighting CSP has been the bane of my career and this issue has defeated me. Seppuku time lol

[CmpHDL]

+1

Folks, nothing has changed with this. You don't need to keep adding comments saying "still an issue".

If there is an actual potential technical solution, the best thing you can do would be to file a PR that implements it. (It's also possible this is fixed in the upcoming DevTools Extension 3.0 version, which is currently in beta - it would help if someone could try it out and actually report on whether that might fix the problem.)

But otherwise, just adding a "still broken" comment is not helpful.

It shows other people have the same issue and that it is a common problem among developers rather than an individual's problem.

[GaddMaster]

Folks, nothing has changed with this. You don't need to keep adding comments saying "still an issue".

If there is an actual potential technical solution, the best thing you can do would be to file a PR that implements it. (It's also possible this is fixed in the upcoming DevTools Extension 3.0 version, which is currently in beta - it would help if someone could try it out and actually report on whether that might fix the problem.)

But otherwise, just adding a "still broken" comment is not helpful.

still an issue :)