-
Notifications
You must be signed in to change notification settings - Fork 229
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
Using CSP breaks IGV.js #1613
Comments
I don't know anything about CSP, but it looks like it is failing when trying to "eval" a runtime plugin for ES5 compatibility. If you are able to use the es6 package (import igv rather than a script include) you should not encounter this probability. Alternatively you could build you own version and remove the "babel" translation step. We are going to do this very soon in any event and drop support for ES5. |
Also, that is not the latest version of igv.js, please try version 2.15.0. I don't think you should see this specific error in the latest version. |
Thank you for your reply. To sum it all up: If you want very restrictive CSP you should build your own version. However, it is also possible to relax the CSP such that it works without changing the code. |
@MarvinDo OK, thanks for the info! |
I am encountering similar issue (with npm package igv version 2.15.11). I had to add the following to the CSP header to bypass the CSP restriction:
About
|
related to our use of the binary-parser library in CRAM (and other GMOD libraries...similar issue reported to the binary-parser library itself keichi/binary-parser#258) |
@cmdcolin Do you know what is inserting "eval" into the cram.js bundle? Is it webpack or babel, and is there a way to build the bundle without it? |
the binary-parser calls "new Function" which is effectively an eval link into the binary-parser source code: probably it will be required to move away from the binary-parser library in cram-js to fix this. it can be done...just will take a bit of time |
@cmdcolin "new Function" would likely be a security problem as well, but I am not convinced that is where the eval is coming from. "new Function" is perfectly fine javascript and would not need a transformation to eval. I know webpack uses eval in some of its transformations, that is one reason we dropped it for rollup. I might take a crack at creating an eval free bundle, but I would like to start from javascript. I assume the "esm" folder that is created during the build is just the javascript generated from the typescript, otherwise unmodified. Is that correct? |
"new Function" is basically equivalent to an eval so it is the reason it warns to my knowledge, and since the warnings are pointing at the cram-bundle, that is more than likely the issue (the new Function from binary-parser in the cram-bundle) since I stirred the pot by commenting on this issue, i started an attempt to purge binary-parser from cram-js https://github.com/GMOD/cram-js/compare/master...no_binary_parser?expand=1 it is not done yet but it's on its way there
yes, it is created from running the typescript compiler over the src folder, without much down-transpilation. but i'd advise to wait to see if i can get my branch working...will try to get an update sometime soon |
OK, will wait. I think it might be several days to a week of work for me to try. There is an "eval" in the cram bundle, you can verify that with grep. I can't tell if that is a consequence of "new Function" or not, but for sure "eval" was in every webpack bundle we ever created for igv.js. There might be options to create an ESM module from webpack that does not insert the eval, I haven't used webpack in many years. |
WRT the injected CSS, which is the other issue noted here, |
yes I actually sort of skimmed over it but we actually use our own custom version of binary-parser named @gmod/binary-parser that forked off from binary-parser a long time ago, and that contained a usage of eval. i am actually happy to try to get rid of it as it would remove our need to maintain it :) note that the latest @gmod/binary-parser has no evals and just new Function but it would likely still trigger the same csp thing (see GMOD/binary-parser@ddc7a7a removal of the vm-browser.js file removed the eval) |
Ahh o.k. I also have a "binary parser" class from ages ago, but am slowly replacing it with DataView. |
went ahead and tried to get it done GMOD/cram-js#137 you can manually clone branch, yarn, yarn build -> get dist/cram-bundle.js or i attached it here :) |
@cmdcolin Wow thanks for the fast work! I did a quick test and get the following error. I can look into this more deeply tomorrow evening, I am out of the office most of the day tomorrow. ReferenceError: Buffer is not defined |
interesting, i think i fixed it in the cram-bundle with a webpack config tweak re-attached here (and updated at pr) |
@cmdcolin I still get the error but I'm considering in igv.js, not cram.js. The previous builds of cram.js apparently created a global Buffer class as a side effect, and I am using Buffer when creating a file handle for the cram library. I'm sure I can recode this without using Buffer. |
interesting, i could make a custom build of cram-bundle.js that sets window.Buffer=Buffer basically the alternative is like you said, recoding it so your app doesn't depend on that dependency but if it's easier to just keep that behavior i can make that custom build to restore it |
here is that alternative build which sets window.Buffer=Buffer |
@cmdcolin That works! I'm still going to try to rewrite this to use browser available classes, we shouldn't be depending on this side effect, but for now it works and no eval! BTW, I do the following to convert the bundle to an es6 module. I don't mind doing it, but thought you might find it helpful if you need a browser friendly es6 module To convert cram-bundle.js to an es6 module: (1) Add an export default statment to the beginning of the file export default (() => {var e = {368.... (2) replace var n = r(5590);return n})(); |
@cmdcolin I'm trying to rewrite my FileHandle class to not explicitly use Buffer. I can't strictly do this as some of the required return types are Buffer, but thought that maybe cram.js doesn't require the entire Buffer interface. Anyway, I found that the first argument to the "read" method, which I expect to be a Buffer base on the type script, is an Uint8Array in every case. This is actually fine, even preferred in a browser, but I'm a bit confused now on what to expect. Is the typescript too strict here, or an Uint8Array considered a Buffer? Another oddity, I just realized the "read" method expects a return value, {bytesRead, buffer}, but I have never returned anything from my FileHandle and its been working. I assume the second argment, Buffer, can be whatever is passed in (an Uint8Array in my test cases), and not an actual Buffer.
|
Actually never mind re type, I think the Chrome developer tools are a bit confused and presenting this as an Uint8Array because a Buffer, I think, is a type of Uint8Array. So it might be difficult to implement FileHandle using just browser native classes as the interface expects Buffer objects for both inputs and return values. Not a big deal, we have been doing this for years now. |
@cmdcolin OK here's what I've done, and we can close this topic here or move it to JBrowse. I'm importing the "Buffer" project from https://www.npmjs.com/package/buffer and using that implementation, which is the same you use in cram.js. Its a bit redundant but what's an extra 60kb when your up to 3.3 MB. So you can remove the window.Buffer hack, I never should have used that in the first place. It just worked so I didn't question it. |
that is probably fine. the cram module uses that same one internally. I have a long term goal to remove Buffer usage from our data parsing libraries eventually, but that will take awhile:) |
The "eval" issue should be resolved. |
@lacek Or anyone else, I'm willing to consider the "nonce" idea for CSS injection but am unsure on how to implement it. A PR or explicit instructions would be welcome. CSS injection occurs here: https://github.com/igvteam/igv.js/blob/f330ef446f39a1ab444b6e6bec77cf619212af09/scripts/embedCssTemplate.js |
Hello everyone,
recently I started experimenting with CSP. When enabled using the "Content-Security-Policy" http header with these options:
default-src 'self' 'report-sample';
the igv.min.js throws a couple of errors:(source location: [igv.min.js:51:45899])
(source location: [igv.min.js:26:116108])
(source location: [igv.min.js:45:20173])
(source location: [igv.min.js:51:45898])
As a result igv is not loading on my webpage.
Is it possible to fix these errors or can you help me with relaxing the CSP such that it works?
I appreciate any help with this.
I am using IGV.js 2.13.9 and Firefox 102.8.0esr (64-Bit)
The text was updated successfully, but these errors were encountered: