search

bgruening / galaxy-ipython

:microscope::books: IPython Integration into Galaxy
MIT License
31 stars 14 forks source link

WebSockets, Passwords, and Apache, Oh my! #10

Closed hexylena closed 10 years ago

hexylena commented 10 years ago

Unknown issue, I'm looking at pcaps and other logs today, hopefully will be able to identify this issue.

hexylena commented 10 years ago 
172.16.49.142 - - [05/Aug/2014:10:12:39 -0500] "GET /ipython/11013/api/kernels/4570a1c6-0983-45b6-996c-1eb9ab802f09/shell HTTP/1.1" 500 - "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0"
172.16.49.142 - - [05/Aug/2014:10:12:39 -0500] "GET /ipython/11013/api/kernels/4570a1c6-0983-45b6-996c-1eb9ab802f09/stdin HTTP/1.1" 500 - "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0"
172.16.49.142 - - [05/Aug/2014:10:12:40 -0500] "GET /ipython/11013/api/kernels/4570a1c6-0983-45b6-996c-1eb9ab802f09/iopub HTTP/1.1" 500 - "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0"

500 internal server error, looks like another CORS issue.

hexylena commented 10 years ago

Strangely, not a CORS issue. Adjusted the hostname in my apache config (the <Location> block) from 127.0.0.1 to fqdn and now I'm actually receiving a 403 Forbidden

HTTP/1.1 403 Forbidden
Date: Tue, 05 Aug 2014 15:17:22 GMT
Content-Length: 35
Content-Type: text/html; charset=UTF-8
Server: TornadoServer/4.0

Cross origin websockets not allowed
hexylena commented 10 years ago

Okay, this is not an SSL issue, my laptop is sitting next to me (without SSL) and I cannot access the IPython kernel from another computer.

hexylena commented 10 years ago

Okay, the 500 is definitely coming from apache and not from IPython, the request is never reaching IPython. Long before it gets to the destination I see the following:

Me:

GET /ipython/10387/api/kernels/4dfe6855-e459-479f-9cc7-bbf5ea64fb99/iopub HTTP/1.1
Host: 192.168.0.103
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: nb-no,en;q=0.7,zh-cn;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Sec-WebSocket-Version: 13
Origin: http://192.168.0.103
Sec-WebSocket-Key: C4m7FpEz8Yv5NHU0pKZTQA==
Cookie: username-localhost-10387="2|1:0|10:1407255171|24:username-localhost-10387|48:NGE4NWNjMDQtOWJhNy00ZWZiLWIyNDctYmM0YmE1YTVkZjFl|f96a689d0a4696b824db2d793152061619ffe1c9f79fbdfbd4cfc36869cb90ad"
Connection: keep-alive, Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket

Server

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: rLvPURNMMJvKSZG3/zpLT+fU0p4=

This is followed by a long response from me an the bytes 80 00 from the server. My client makes another request (88 80 e0 80 52 7a) and then apache tosses up an html page with an error:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>500 Internal Server Error</title>
</head><body>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator at 
 webmaster@localhost to inform them of the time this error occurred,
 and the actions you performed just before this error.</p>
<p>More information about this error may be available
in the server error log.</p>
<hr>
<address>Apache/2.4.7 (Ubuntu) Server at 192.168.0.103 Port 80</address>
</body></html>
hexylena commented 10 years ago

Okay, the proxying is working mostly correctly, but something is still happening in there that isn't clear.

I changed the rewrite rule to match (stdin|stdout|shell) as I knew those were the names of three of the websocket endpoints. In the logs I saw a call to /api/kernels/$uuid/iopub which failed with a 400 bad request, something that might happen if websockets were going to an HTTP server, while stdin failed a few lines below with a 500.

hexylena commented 10 years ago

As of yesterday, definitely only occuring under the conditions of apache_urls and password_auth

hexylena commented 10 years ago

Problem no longer exists on loading branch, so closing.