- Removed a statically set port during testing
- Made variables local so we can be sure they aren't being mis-used
- Removed sleep
- New parameters needed in notebook load call
- Added main div to use for images/etc. Probably not necessary.
Many people will be intially overwhelmed by the stack trace they see within galaxy in
the even of a missing API key. Hopefully, hopefully, they'll be able to read the bold
portion at the bottom with instructions on generating one. It's mostly a measure to
decrease support tickets/requests
I've found in opera that copy+paste doesn't work, so I have to drag and drop. Additionally, we need
the user to have time to read and comprehend what we're telling them before this notification
disappears forever.
Despite the fact that this is technically a configuration bug on the sys admin's part, for a future
release, we should switch to a different type of notification, probably like a banner with an X that
they can close once they're done reading it. That way we know it'll be there as long as they need it
to be.
Previously in a specific situation (apache_urls = False and password_auth = True), we saw that users
would see a blank screen rather than an informative error message. This should not happen under any
circumstances.
This has been replaced with logic to handle the failure modes in as sane of a way as possible. If
the above situation is true, we provide the users with their random password and a login box. If any
other bad situation occurs, we pass the error message along to them.
Additionally a new variable "password_auth" has been introduced, describing whether or not passwords
should be used to authenticate users (mostly auto-magically) against their notebooks.
Because we have control over this docker image, it is possible we can handle that specific case
above by convincing ipython to set a content-origin header allowing the galaxy host to make the JS
login request.
Now whenever a notebook is loaded we first do a POST to the notebook login URL with the correct
authentication details. This logs us in and stores a cookie for us. Once this is done, (and we know
we were successful) we add the embed/object elements to the body of the page, which the browser then
loads.
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.
Eric Rasche