Flashing nodes with HTTPS Apache Reverse Proxy does not work due to broken URLs

[BastianPoe]

To make the wisegui accessible via HTTPS I have installed an Apache Reverse Proxy "in front" of the wisegui. Login works perfectly and nodes can also be flashed. However, the browser tries to access the result of the flashing process via HTTP (instead of HTTPS) and fails to do so.

To flash the nodes my Chrome does the following request:

Request URL:https://HOSTNAME/rest/2.3/local/experiments/EXPERIMENT_KEY/flash
• Request Method:POST
• Status Code:200 OK
• Request Headersview source
• Accept:/
• Accept-Encoding:gzip,deflate,sdch
• Accept-Language:de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4,da;q=0.2
• Connection:keep-alive
• Content-Length:76524
• Content-Type:application/json; charset=UTF-8
• Cookie:_jsuid=3407167005; __utma=203527240.979389698.1345708507.1383895125.1385381684.18; __utmc=203527240; __utmz=203527240.1383895125.17.12.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); wisebed-secret-authentication-key-local=KEY
• DNT:1
• Host:HOSTNAME
• Origin:https://HOSTNAME
• Referer:https://HOSTNAME/
• User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36
• X-Requested-With:XMLHttpRequest
• Request Payloadview source
{configurations:[{nodeUrns:[urn:local:0x0001],…}]}
• configurations: [{nodeUrns:[urn:local:0x0001],…}]
• Response Headersview source
• Connection:Keep-Alive
• Content-Encoding:gzip
• Content-Length:204
• Content-Type:text/plain
• Date:Mon, 02 Dec 2013 14:33:12 GMT
• Keep-Alive:timeout=5, max=100
• Location:https://HOSTNAME/rest/2.3/local/experiments/EXPERIMENT_KEY/flash/SESSION
• Server:Jetty(8.1.1.v20120215)
• Vary:Accept-Encoding

Then the wisegui tries to figure out the status of the flash process and issues the following request:

• Request URL:http://HOSTNAME/rest/2.3/local/experiments/EXPERIMENT_KEY/flash/SESSION
• Request Headersview source
• Accept:application/json, text/javascript, /; q=0.01
• Origin:https://HOSTNAME
• User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36

It appears, that wisegui constructs the wrong URL for obtaining the status.

[danbim]

The issue is a bit tricky. TR receives the request for flashing nodes and returns a URL on which the status of the flash process can be queried over time. This URL is constructed using the request URL that was used during the invocation of the flash operation. TR itself gets this request from the proxy so it totally makes sense that TR "rewrites" the URL to "http" instead of "https" because it is running on "http". As only the proxy knows of its own existence to me it would make sense that the proxy also rewrites the URL in the "Location"-header of TRs response before forwarding it to the client. I'll investigate this...

[danbim]

Did you use the ProxyPassReverse directive in your proxy configuration? From a first look, this should do the trick...

[BastianPoe]

Thank you very much for your response. We have been using said directive, but it does not change anything. In fact the documentation says, that "Only the HTTP response headers specifically mentioned above will be rewritten". As you can see in original issue, the server in fact responds with a "Location: https://HOSTNAME..." so everything seems to the ok. Still, the request from the browser is then going to "http://HOSTNAME" and fails.

In fact the problem occurs due to the following: The browser uploads the image to this URL:
https://wisebed.ibr.cs.tu-bs.de/rest/2.3/local/experiments/SESSION/flash

The response is the URL where the browser can track the status of the flash operation. In our case, the response is:
http://wisebed.ibr.cs.tu-bs.de/rest/2.3/local/experiments/SESSION/flash/MDA4NjM4Njg5OEQ3REM0MUM4RTUzRkNCMzZGQ0FEQTM=

This is exactly the URL the browser tries to access in the next step (in wisebed.js line 255: var flashRequestStatusURL = jqXHR.responseText;). This is bad (at least in our case) since it will always force the browser to use http (since this is where the ws thinks it is running). An easy fix would be to ignore the protocol the server sends and to always use window.location.protocol.

[danbim]

I suppose then that line 255 is responsible for this behavior as a result of the reverse proxy modifying the Location header but not modifying the response body. The comment indicates that once upon a time we had issues with cross-site environments where the Location header would be empty. Can you try to uncomment line 254 and comment out 255 and try it again in your environment and see if this works?

[danbim]

Ups, sorry. I forgot to link to the impl file that I was referring to above :)

https://github.com/wisebed/wisegui/blob/master/js/wisebed.js#L253

[BastianPoe]

Yepp, this actually fixed the problem. Thank you very much for your help! Is that something that you can include in the general git?

[danbim]

I guess I can now do it as WiseGui is no longer used as a proxy in rest-ws but is embedded into TR :)