NodeJS dashboard app backend

[parente]

The draft https://github.com/jupyter-incubator/dashboards/wiki/Deployed-Dashboard-Threat-Analysis points out a bunch of (obvious) vulnerabilities with the current dashboard implementation. Some of these can be addressed by implementing a more powerful dashboard app backend, not just a simple PHP file that renders HTML.

The details need to be fleshed out, but the gist described in the countermeasures would be:

1. Dashboard backend is a full-blown web app implemented in, say, NodeJS.
2. NodeJS app can be configured to work over HTTPS, not just HTTP (in case it is not running behind a proxy that provides SSL termination.)
3. NodeJS app has an option to prompt for a shared username/password via a login form it provides (or basic auth or ...).
4. After successful login, NodeJS app serves up an HTML file with the desired dashboard layout placeholders, the new jupyter-js-services, jupyter-js-output-area, etc. from Replace thebe with jupyter-js-services, jupyter-output-area #105 but NOT the code from the notebook.
5. On page load, the JS in the browser requests that the backend NodeJS app execute all of the original notebook code in top to bottom order. The NodeJS app uses jupyter-js-services to do so and proxies the results back to the frontend where they are stuffed into the proper output areas in the layout
6. The NodeJS app then proxies all Jupyter comm channel requests from the browser to the kernel as well as responses on iopub, shell, etc., but does NOT allow any other shell commands from the browser JS to the kernel.

[parente]

/cc @jhpedemonte @dalogsdon

[dalogsdon]

Status update:

We have a node app that can intercept WebSocket messages and renders the dashboard. No code is sent to the client. Markdown cells are rendered. We are currently working on the code execution to send the execution results to the client.

[parente]

Opened the https://github.com/jupyter-incubator/dashboards_node_app repo where this work should be delivered. Something we should discuss: do we want to use the issue tracker over there or just keep everything here so we don't have to hop all over?

[parente]

Another thought, too. As I understand it, the new node app just points to a notebook as the source of the code to execute on the kernel. But if that notebook uses any declarative widgets, it's going to need to package those too. This is really a bundler problem, but it does place one requirement on the node app: it has to have a directory for static web assets that it will serve up. The bundler or npm/bower will need to place all the frontend assets (declarative widgets, polymer widgets installed by urth-import, etc.) into this directory.

[dalogsdon]

do we want to use the issue tracker over there or just keep everything here so we don't have to hop all over?

I think we should start tracking over there since there are already multiple unwritten issues to tackle. I'd rather do a little bit of hopping initially than read through a long discussion on this high-level issue.

[parente]

Works for me. 👍

[rgbkrk]

You all move so fast and so well.

[parente]

Opened jupyter/dashboards_server#1 over in the new repo. It lists the items for the initial implementation. I'll open a few more issues about implementing the other minor improvements noted here.

Going to close this one out since there's nothing else to do in this repo (or shouldn't be).

[parente]

@rgbkrk ☕ and 💻s!