Debugging interactive app launch

[mcuma (Martin Cuma)]

We are setting up OOD in our Protected Environment (PE) that may be having some extra quirks so we are having trouble getting the interactive apps work, that work fine in the general environment (GE).

One issue is the Jupyter server - fairly standard app setup with the Jupyter being launched via the view.html.erb POST as:

Connect to Jupyter

Is there a way to set up some more verbose logging on the server, or see something more in the Inspector so we see how the POST method is being executed?

In our case, in the GE, pushing the “Connect to Jupyter” button passes in the password and launches the Jupyter file viewer (“tree”) in another browser tab - the correct behavior.

In the PE, the password seems to not be accepted and we’re presented with Jupyter login screen, asking for password, which if we enter from the connection.yml in the app’s running directory, we get logged in the Jupyter.

We’re trying to see some logs that would show us if the password is being passed to the server in the PE. I don’t see anything of use in the /var/www/httpd24, in fact, I see the POST in the access_ssl log with some basic info when I push the “Connect to Jupyter”, button, but nothing in the error_ssl log.

In the Inspector view on the client web browser, we’re given a server response that JavaScript is missing, though it’s enabled in the browser, and, the server (on the compute node) has it installed and functional (nodejs). So, I am not sure about that response, especially since I need to push Reload of the Jupyter tab to see all the network traffic in the Inspector. I can’t seem to figure out how to enable the Inspector on the first push to the “Connect to Jupyter” button.

Even more bizzarre is, if I push the “Connect to Jupyter” again, the Jupyter gets launched. So, something is blocking the first push, but lets through the second.

In either case, if anyone has some extended logging/debugging tips, it’d be appreciated.

Martin

[jeff.ohrstrom]

@mcuma

if I push the “Connect to Jupyter” again, the Jupyter gets launched. So, something is blocking the first push, but lets through the second.

Do you use Shibboleth authentication? This sounds like a CASScope issue.

Jupyter app ask for password first time, works second time

OK forget the authentication bit. It looks like you’re correctly passing auth in the first request. Let’s now assume it’s a problem with redirection and maybe setting and passing cookies. Sorry it took this long to get here. Here is what a correct redirection flow is. Notice the status codes received from login and 55808 are 302 Found. [image] Seems that your 302 redirects are not working the first time? Here’s what my very first 302 redirect response looks like. See the locaion is rela…

In terms of debugging - you’re web client is your best bet for this situation - it’ll tell you what’s going on - where you’re being redirected to (if it’s the right location with the right credentials and so on).

[mcuma (Martin Cuma)]

Thanks Jeff, that did it! That is, adding ‘CASScope /’ in ood_portal.yaml. I think it’d be good to improve the docs on the CAS to mention this since we missed that info in the thread and spent a week chasing different ideas in troubleshooting this. I’d be happy to write something up once we finalize the description of our setup for our internal purposes.

[jeff.ohrstrom]

I made a ticket on our documentation repo. Pull request welcome!

That said - I’d invest in some automation. We have puppet modules and ansible roles available.

[mcuma (Martin Cuma)]

Thanks Jeff, I’ll talk to our admins about the automation.