Job files can't be loaded in Chrome when using HTTPS due to insecure content

[twstdpear]

I'm not sure whether this is an issue in Octoprint, Octopi or a combination since Octoprint doesn't do HTTPS on its own. It looks like some requests are still going over HTTP even though I'm accessing the server via HTTPS.

Chrome version is 38.0.2125.111 (64-bit) under Linux. In Chrome's developer console, I get the following when attempting to load a gcode file to print:

[blocked] The page at 'https://hostname.domain.com/' was loaded over HTTPS, but ran insecure content from 'http://hostname.domain.com/api/files/local/Z-Axis_LM8UU_Bearing_Holder.A6.gcode': this content should also be loaded over HTTPS.
x.support.cors.e.crossDomain.send jquery.min.js:6
x.extend.ajax jquery.min.js:6
GcodeFilesViewModel.self.loadFile files.js:142
click VM311:3(anonymous function) knockout.js:62
x.event.dispatch jquery.min.js:5y.handle

If I click on the shield at the top, to "load unsafe script", I receive the following message instead:

XMLHttpRequest cannot load http://hostname.domain.com/api/files/local/Z-Axis_LM8UU_Bearing_Holder.A6.gcode. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://hostname.domain.com' is therefore not allowed access.

This seems to have started happening sometime in October, but I'm not sure exactly when. I can replicate it using a fresh install from 2014-09-09-wheezy-octopi-0.10.0.zip (* master 644329c Preparing release of 1.1.1), as well as an install from 2014-01-07-wheezy-octopi-0.8.0.zip with Octoprint which had been periodically upgraded via the recommended method ultimately to whatever was available in Github as of the evening of 2014-11-05, which was where I originally discovered it.

[guysoft]

1. Does it acutlaly say " http://hostname.domain.com"?
2. Did you approve the self-signed ssl certificate from the hompage for a start?
3. @foosel , did you see this before? It might be an OctoPrint issue.

[twstdpear]

1. No. Given that this was going the posted publicly, I changed the hostname. I didn't change anything else, however. The original host names displayed were the fully qualified names of my printer, but they just used "http" instead of "https" as indicated above.

2. I'm not certain what you're asking. When I first accessed the system, I did tell it to proceed even though it couldn't validate the cert (wrong hostname, and self-signed). I do have the ability to issue my own, signed cert, but I'm doubtful that would change the outcome given that the error messages were reported by Chrome are saying it can't connect to http://hostname.domain.com. I'll try this again here in a few minutes to see if it makes a difference, but I'm doubtful it'll change much.
   This same setup was working fine up until recently.

3. I had looked back through the issues of both projects before reporting this, but didn't see anything obvious.

[twstdpear]

2. Using a valid cert (not expired, correct FQDN, and signed by a trusted CA) makes no difference in the behavior described above.

And just to be clear, it's not just the load button, the delete and load+print buttons behave similarly.

[foosel]

@guysoft the haproxy.cfg shipped with OctoPi apparently doesn't configure necessary environment variables (see here towards the end) for OctoPrint to generate the correct download URLs. That only causes problems in case of access via SSL (since it defaults to http if the X-Scheme header isn't set explicitely to https).

[twstdpear]

Based on the haproxy recommendations on that page, I changed the frontends and backends as follows, and it seems to fix the problem. I left everything in the file above the frontend definitions alone.

I tested this with one front end disabled (commented out), then the other, and finally with both enabled. It seems to work in all three cases for anything I could think to test aside from doing an actual print.

frontend public
bind *:80
option forwardfor except 127.0.0.1
use_backend webcam if { path_beg /webcam/ }
default_backend octoprint

frontend public-ssl
bind 0.0.0.0:443 ssl crt /etc/ssl/snakeoil.pem
option forwardfor except 127.0.0.1
use_backend webcam if { path_beg /webcam/ }
default_backend octoprint-ssl

backend octoprint
reqrep ^([^\ :])\ /(.) \1\ /\2
option forwardfor
server octoprint1 127.0.0.1:5000

backend octoprint-ssl
acl is-ssl dst_port 443
reqrep ^([^\ :])\ /(.) \1\ /\2
reqadd X-Script-Name:\ /octoprint
reqadd X-Scheme:\ https if is-ssl
option forwardfor
server octoprint1 127.0.0.1:5000

[guysoft]

We are still using 1.5-dev19, we could upgrade to 1.5.8.

[foosel]

No need to upgrade haproxy (although it would of course be nice too), just
extend the configuration so that it includes addition of the X-Scheme
header where necessary

[guysoft]

@foosel Not sure how to do taht, if you could pull request I could release 0.10.1 with the fixed config and a bran new haproxy :)

[foosel]

@guysoft Currently busy with other stuff, but if I'm not mistaken that should be enough:

--- haproxy.cfg.old     Sat Nov  8 13:55:02 2014
+++ haproxy.cfg.new     Sat Nov  8 13:56:07 2014
@@ -28,6 +28,7 @@

 backend octoprint
         reqrep ^([^\ :]*)\ /(.*)     \1\ /\2
+        reqadd X-Scheme:\ https  if is-ssl
         server octoprint1 127.0.0.1:5000

 backend webcam

[guysoft]

Ok, So I will add a small fix to that. We released an experiential version and found it needs a bit of adjustment. Gina posted:

https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#7.3.4-ssl_fc
Looks like is-ssl has been removed in favor of ssl_fc. I'm fairly sure it used to work.
Fix should be to remove the reqadd ... is-ssl line from the backend section in haproxy and instead add
http-request add-header X-Scheme https if { ssl_fc }
I can't test this right now though, I'm up to my neck in other things

Link to that is here:
https://plus.google.com/u/0/+GuySheffer/posts/7QYqThV5xbP

[foosel]

This works (also added to the corresponding OctoPrint wiki page):

backend octoprint
  reqrep ^([^\ :]*)\ /(.*) \^\ /\2
  reqadd X-Scheme:\ https if { ssl_fc }
  option forwardfor
  server octoprint1 127.0.0.1:5000