I noticed that the cookie was indeed being set by the POST request. However, that cookie was
essentially ignored in the subsequent requests.
I looked for places to interrupt it, could I just stop after the POST and not execute any redirects.
That did not appear to be an option due to HTTP/XHR spec. After a bit of searching I came up with
this link: http://stackoverflow.com/a/14462615 which seems to solve the issue. Mentioned here:
https://api.jquery.com/jQuery.ajax/
- 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.
Bjoern Gruening