To allow for server administrators to easily secure IPyNBs, we have to stop serving over ports, and
start serving under a sub-path. This change will require the introduction of apache configuration as
a hard requirement for rewriting URLs properly to the backend.
For a given Port $P, IPyNBs are started, listening on 127.0.0.1:$P/ipython/$P/. These are accessed
through that url within galaxy. For the apache style configuration, we remove the first $P and
simply access notebooks at "127.0.0.1/ipython/$P/" which allows the administrator to apply SSL to
the /ipython/ path, thereby securing the notebooks.
A couple things of interest are done with the template:
- HTML header
- Markdown cell with instructions as to read/write data from galaxy
- A HIDDEN javascript function to save to galaxy
- Empty cell for next user command.
The hidden javascript function is done by writing the function as part of the notebook and removing
the input text. This is probably very, very fragile and will not survive a closing+reopening but
it's very pleasant looking to just have a button that saves the notebook to galaxy. It's very
visually unobtrusive and that may be more important for new users than having the full code there.
To be able to interact with that button it is required that ipython trust the notebook. This is done
in an update to the docker startup script.
See the [PyYAML](http://pyyaml.org/wiki/PyYAMLDocumentation) docs for more information as to flow
style. Essentially it should make sure the `conf.yaml` file is greppable, which may be necessary for
IP address whitelisting.
In order to whitelist IPs allowed to connect to notebooks, we need to know who the remote target
connecting is. We can blacklist on IP address only, as we have no way of authenticating them. While
we do have access to other information like cookies, we have no SSL nor way to know what
authentication method the galaxy server will be using.
The original version actually failed for me. I am led to believe that all the pipes were being
passed to netstat as it said "I don't understand the option ':'" which came from the cut command.
At the cost of simplicity, this should do what we want properly. Alternatively we could move the
awk/cut/sort into python.
`request` provides a `host_url` like "fqdn:port" from which we can extract the FQDN that this server
was accessed at. This is important so that we are accessing the IPyNB on the correct host.
Rather than assigning a static notebook signature, this has been replaced with a randomly,
deterministically generated notebook signature. This is currently done off of the dataset's id,
encoded through trans (so it's the unique hash, and not just the number), however this will need to
be exchanged for history_id whenever we have access to that.
Bjoern Gruening