I am trying to use my custom javascript libraries by static hosting them on S3 and referring the https url in my generic javascript view node. I am getting an error on version 5.2.5, 5.4.4 and 5.5.0 version.
Before in the javascript code we are referring the paths of the libraries to variables.Now replacing this path with s3 object url. The workflow should first access that S3 bucket and then the libraries inside the workflow.
Anyone using custom libraries through this method? Is there a workaround
Sorry for the late reply. I tried to find a proper solution, but I couldn’t.
I got some internal feedback that you could try it out and play around with it a bit.
Download the scripts inside the workflow using KNIME S3 integration, then pass the code to the Generic JS view using flow variables
Use the URLs of the scripts with require.js. This should work, however, you would definitely play around with CSP headers.
That’s all I have, hope it will be enough for your to figure out how to achieve your goals!
I can tell you what approach I used, so that it will be easy to understand:
I pushed the JS libraries to S3 bucket and enabled static hosting for the bucket.
Used the url’s of libraries inside the script of generic javascript node.
There is a compatibility issue with jQuery and jQueryUI so I have added those library files as well to the respective S3 bucket and used the path in the script by unchecking the jQuery and jQuery UI in the node.
This worked for KNIME AP, and I got the expected dropdowns in the output. But it is not working for KNIME Hub. So, wondering what changes I should do to make it work in Hub.
the problem does sound like a CSP header issue on your Hub installation. If it works locally in an AP, the S3 setup seems to be correct. For Hub to be able to load external scripts or resources (like S3) an exception needs to be added to the CSP header for those specific domains (e.g. https://my-bucket.s3.eu-central-1.amazonaws.com I would also suggest you do not use the wildcard character here (e.g. *.s3.amazonaws.com) because that would allow arbitrary buckets and could potentially be a security issue. For custom domains that is a valid approach, but here I would say stay as specific as possible.). If there is a resource that is trying to be accessed that is prohibited there should also be an error logged in the browser console. That is how you should be able to verify that the CSP header is in fact the culprit here.
As to which directives to use, it depends on the type of resource being requested. script-src will cover every JavaScript file, but if e.g. jQueryUI also loads a CSS file it would need to be added to style-src as well. Alternatively if no script-src (or style-src or other) are defined the value of default-src is used for that particular case. Her you can find more information about the Content Security Policy headers: Content-Security-Policy (CSP) header - HTTP | MDN
That’s all I can say on this topic. I hope this helps you find the right solution for you!
I hope this helps you find the right solution for you!