Make Kolibri compliant with a secure Content Security Policy

[rtibbles]

Summary

• Use JSON in <template> tags rather than inline <script> tags for all our injection of data into the frontend from the backend
• Add our own frontend parser (with lazy resolution when Proxies are available) for generated URL JSON data from django-js-reverse
• Now requires that all frontend URL name references only use snake_case and no kebab-case.
• Updates how we register i18n frontend messages, by updating our webpack configuration to inject the registration logic as the first thing to happen in the bundled JS - unless it is the core bundle, in which case it happens last, to let the core global object to be defined first
• Resorbs the browser checking into the core bundle, as it increased complexity of our code, and was putting people with incompatible browsers at higher priority than our frequent users
• Cleans up all our unused (non-content renderer specific) async module loading code that was relying on injected JS
• Turns our in-context translation into a plugin that is not enabled by default, gets rid of the inline JS that it previously relied on and load it via a script tag
• Adds the Django CSP middleware to Kolibri, and sets sensible defaults that allow Kolibri to function fully in both production and dev modes.
• Adds a single CSP related deployment option to globally add host-sources to the CSP - this is done simplistically for now, and assumes that finegrained control is either not required, or can be achieved by directly changing settings if needed.

References

Fixes #12809

Note: it goes slightly beyond what is outlined in the issue, by actually adding the CSP headers as well with Django CSP, but it seemed like the only way to show it was working as intended!

Reviewer guidance

Do any assets not load properly, is anything too strictly defined for proper functioning either in production or development mode?

Is anything too loosely defined? One particular thing to note is that the iframe src is very permissive when ZIP_CONTENT_ORIGIN is not defined, because we can't set a port on self - so if we wanted to make it stricter, we'd have to dynamically set the CSP based on the host that Kolibri was accessed from.

[github-actions]

Build Artifacts

Asset type	Download link
PEX file	kolibri-0.18.0a0.dev0_git.9.gf16648d1.pex
Windows Installer (EXE)	kolibri-0.18.0a0.dev0+git.9.gf16648d1-windows-setup-unsigned.exe
Debian Package	kolibri_0.18.0a0.dev0+git.9.gf16648d1-0ubuntu1_all.deb
Mac Installer (DMG)	kolibri-0.18.0a0.dev0+git.9.gf16648d1.dmg
Android Package (APK)	kolibri-0.18.0a0.dev0+git.9.gf16648d1-0.1.4-debug.apk
TAR file	kolibri-0.18.0a0.dev0+git.9.gf16648d1.tar.gz
WHL file	kolibri-0.18.0a0.dev0+git.9.gf16648d1-py2.py3-none-any.whl

[bjester]

One major question about script-src being loose

Also, outside of the scope of the issue, I wonder if we should think about adding Access Control headers.

In testing, I noticed some 404s when viewing an African Storybook HTML5. It does seem to be affecting it because compared to the catalog server, it looks very different.

[rtibbles]

In testing, I noticed some 404s when viewing an African Storybook HTML5. It does seem to be affecting it because compared to the catalog server, it looks very different.

Interesting - the Django CSP middleware shouldn't be affecting anything inside the iframe, but maybe something is happening inadvertently!

[rtibbles]

Hrm, I replicated the 404s in African Storybook, but they seemed to be because the files are actually missing from the zip file, and I replicate exactly the same 404s on develop too.

[rtibbles]

Updated with feedback, will add a note to PR description about making URL names in the frontend more strict as a result.

[bjester]

LGTM

[bjester]