-
-
Notifications
You must be signed in to change notification settings - Fork 37
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
Remove inline JavaScript to comply with some CSPs #145
Comments
The base.html template fills the onload attribute this way: |
Would you be able to submit a PR ? What about:
Also, it looks like there's an unused |
@eshellman Thanks for the quick reply. Are these templates that are filled at build time? Or are they processed client-side? |
@rgaudin That looks a bit like ReactJS to me, but it might be some other templating system... We realize it may not be possible to eliminate all inline scripting for ZIMs that rely heavily on custom UIs, especially those made with React. But if we can ensure a base level of accessibility for clients with restrictive CSPs, it would be really helpful. |
I believe it's Jinja templates, rendered at build time. Fixing this onload seems doable. What about that link I mentioned above? |
This looks like the inline link that users can click (from any book cover) to see more books by the same author. It's also blocked by the Chrome Extension CSP, so again that could be a link added from within one of the attached JS files. Code needed would be to give that anchor an ID (let's say
Code untested of course! |
This issue has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions. |
With openedx an kolibri, this is the last of this kind in all our scrapers. Would be really great to have it fixes and allow KiwixJS to fully enjoy Gutenberg ZIM files. |
This is a priority bug in case there is a doubt somewhere. Have pinned it. |
Just to say that. having experimentally (and successfully) ported the Kiwix JS chromium extension to the next-generation manifest v3 format,, the CSP block on |
This is the same issue in Gutenberg that has been reported for PhET here: openzim/phet#134 . To summarize, Content Security Policies of browser extensions forbid running inline JavaScript. Our ZIMs should avoid having JS inline, and should put required blocks in separate js files. For example, in the landing page of Gutenberg ZIMs, we have:
<body onload="init(); showBooks(); " class="pure-skin-gutenberg home">
This could easily be replaced with a much safer bit of code in the JS file (
tools.js
) whereinit()
andshowBooks()
are defined. All that would be needed is something like:For more info, see kiwix/kiwix-js#789.
The effect of the current inline JS can be seen in our Chromium extension. Compare the left screenshot from the PWA version with the screenshot from the Chromium extension (both running in Service Worker mode, and both capable of running JS). The books are not shown in the extension because
init()
andshowBooks()
are blocked by the CSP.The text was updated successfully, but these errors were encountered: