How to move webworkConfig out of inline JavaScript in templates/layouts/system.html.ep

[taniwallach]

I am interested in getting the core WW2 functionality to work with a Content-Security-Policy which does not use unsafe-inline for script-src.

I'm not sure what is the best approach to replace the script block in templates/layouts/system.html.ep which sets the value of webworkConfig (and the value of webwork_url inside that object).

It seems one option would be to create a .js.ep template file, and have the controller handle requests for that file.

I'm not sure if it feasible to just add the standard value into htdocs/js/System/system.js and then somehow update that value if needed via a value passed in somehow in the HTML code (via a hidden form field?).

At present, I am working around this by using a hash value for the script block generated in the CSP. It could be that might remain the best approach, at least for now.

@drgrice1 Your advice on how to best approach this would be appreciated.

[drgrice1]

A script-src nonce value would probably be the only real way that this can be done. Then there is not need for something like .js.ep template. Basically, for each request there would be a nonce generated for that request. Then all inline scripts and css style tags that we want to allow would need to have the nonce attribute added with that nonce value, and content security policy script-src would need to be set to that nonce value for that request.

The script tag in templates/layouts/system.html.ep where the webworkConfig is defined would just need that nonce attribute to work. Note that you could not replace the webworkConfig with a hidden form field. There is a lot more to the webworkConfig variable than what is set in system.html.ep. It is used several places in JavaScript and other values added to it that are not just text.

That approach could be made to go all the way for PG. A new translation option would need to be added to PG that is the value of this nonce. Then everywhere in PG that we want to allow inline javascript or css, that nonce attribute would need to be added.

[taniwallach]

Thanks! For now - I'm handling this script using a hash in the CSP. Without that - various things fail to work, in particular the problem display in the set-editor and the preview display in the problem editor.

The nonce based approach would also require creating some reasonable manner to manage the dynamic creation of the CSP.

That is fare more than I think is wise to try to do before the pending release. It can wait for after the release when develop is up-to-date.

About the matter of using a nonce for styling. Right now, our info-security people are willing to allow me to keep unsafe-inline for style-src. They complained only about it being a high severity problem in script-src. We have some problems which "broke" mid-semester due to the security demand, but for now - hopefully almost everything we are using is still working.