minimal access in production mode

[drdrew42]

Use the ENV{MOJO_MODE} environment variable to manually set 'development' or 'production' mode for running the renderer.

Note that running the renderer app with morbo will automatically set this value to 'development', while running with hypnotoad will set the value to 'production'.

All routes (except /render-api and /webwork2_files) are blocked in production mode.

Also, in production mode, requests to /render-api must be made with JWE, rather than as raw form-data or x-www-form-urlencoded.

[drdrew42]

fixed exception templating to prevent log-spam

[taniwallach]

I suspect that the current change is not enough.

1. It seems that reusing a valid prior value of problemJWT would suffice to prevent development mode from refusing to process a render request.

• Any value will pass the first test, but an invalid JWT would fail to work if when it could not be decoded.)
• This is challenging to overcome, as expiring a JWT "too soon" would cause problems when the problem was left open for a long rime.

2. The code assumes that all "critical" API fields will be provided by the JWT claims, so any such setting not included in problemJWT could in principle be provided by the regular data provided.

• One option would be to clear the values of "critical" API fields from what was provided outside the JWT before processing the claims in the JWT.

[taniwallach]

Another thought - people who want to use the Docker approach and have the editor available on "localhost:3000" need to be told how to start up the container so that it will get into development mode (with hypnotoad) which is what is being run in Docker.

[drdrew42]

Another thought - people who want to use the Docker approach and have the editor available on "localhost:3000" need to be told how to start up the container so that it will get into development mode (with hypnotoad) which is what is being run in Docker.

Agreed - I need to think this through and find a good way to pass the MOJO_MODE parameter into the container on startup... please share if you have suggestions.

It seems that reusing a valid prior value of problemJWT would suffice to prevent development mode from refusing to process a render request.

I don't think I understand what you're getting at here. The way I'm thinking of growing this out is to wrap the original problemJWT in the sessionJWT... this means that the sessionJWT will enforce a consistent use of the original problemJWT. Maybe that's not what you're getting at, though...

Also, yeah, an exception will should be thrown any time an invalid JWT is provided.

The code assumes that all "critical" API fields will be provided by the JWT claims, so any such setting not included in problemJWT could in principle be provided by the regular data provided.

Indeed. That is by design. Anything configuration that a CMS wants enforced must be included in the initial problemJWT. That JWT is then wrapped into the sessionJWT and remains untouched throughout the user's interaction with the problem. I would like to introduce the ability to 'overwrite' the session's problemJWT (use case: problem is bugged) - though we could always 'force' a restart by dumping the session and starting from a 'fresh' problemJWT... I just don't like dumping data. It won't matter too much in this case, as the interaction data is invalidated by being paired with a dysfunctional problem.