Make escaping for json simpler and more consistent in Mako templates
- add escape_json_dumps to escape and json.dumps
- add escape_js_str to escape javascript string
- refactor Studio to use escape_json_dumps in Mako templates
TNL-2646: Escape json.dumps
Removing this particular call to json.dumps was done by removing
the complete method subsection_handler which is no longer
used. The template edit_subsection.html had already been removed.
TNL-2646 Escape json
- Resolve SEC-27 by escaping course name in advanced settings
- Add escape_json_dumps to simplify escaping json in Mako templates
SEC-27: XSS/JS Error in Advanced Settings with invalid course name
On devops recommendation, now handling the potential for an 'inconsistency
window' via a management command instead of a hacky "re-run the data migration"
bash script.
This includes:
* Ability to specify number of processes to run bok-choy tests in
* A forked nose commit to get the multiprocess plugin's logging to work
* A different plugin (xunitmp) must be used for pulling together xunit results
This works by:
* Starting the various servers that are needed for the acceptance test environment
* Running the tests themselves in multiprocess mode
The only time it should include the suffix is when the handler is
explicilty "xmodule_handler", meaning it's an old-style handler
that routes everything. For example, Capa uses one handler for
all its AJAX requests, and only differentiates actions based on
suffix ("get", "problem_check", etc.).
What prompted this change is that LTIDescriptor defines a handler
"lti_2_0_result_rest_handler" which encodes user-specific
information into the suffix. This is a perfectly valid thing to
do, but it blows out the number of named transactions in our
metrics.
This was originally contributed upstream by Stanford, circa 2013.
We neither use nor support this feature in its current implementation,
and in fact, we may never have used this production. Until recently, we
had additional chat/Jabber code [1] (in the form of a Jabber djangoapp in
LMS); context there suggests this feature may have never been more than
a prototype. The original author is no longer on the team, so I can't directly
confirm this on our end.
Do you use this feature?
Stanford had already abandoned this Jabber-backed chat implementation,
in favor of an IRC backend, by the time I joined the team in early 2014.
[1] dbe52a6b13
