BasicUI mixed content requests (https AND http)

Setup, Configuration and Use Runtime
1

Hi,

recently, I installed OH2 (openhabian, RPi2). This is a great leap forward from OH1 :smiley:

From the internet, I access BasicUI via an HTTPS-reverse-proxy.

The webpage (showing the sitemap) is reloading every 10 seconds and each time shows the message

Offline: waiting for connection to become available

at the bottom of the screen.

BasicUI tries to connect to the following event source:

http://MYSERVER/rest/sitemaps/events/UUID?sitemap=SITEMAP&pageid=PAGE

(placeholders used). However, the protocol for the request is HTTP instead of HTTPS, hence the connection cannot be established. It seems to me that this is the cause for the behavior described above.

Is this desired behavior? Is it a bug? In my understanding, this request should be done over the same protocol as the initial request, namely HTTPS.

Thanks in advance!
ugh_bough

2

This is a bug, if possible open a bug request on github. I’m not sure though, if basicui is part of openhab2 or eclipse smartphone, you would need to find this out.

It is generally not a good idea to make basicui or classicui available for public access. The webserver part is not at the latest version. But you are hopefully securing it with an authorization method at least.

Cheers David

3

It is part of the eclipse smarthome project, thanks for the remark. Bug is reported.

Yes, access is secured and needs authentication :slight_smile:

Cheers
ugh_bough

PS: Any further comments are still very welcome.

4

@Kai pointed out in https://github.com/eclipse/smarthome/issues/4364 that the problem is not in the software, but in the reverse proxy configuration.

Problem
In the reverse proxy, the SSL connection is terminated, and the request is forwarded to the openhab server via HTTP. However, the fact that the original request was issued via HTTPS is not forwarded.

Consequence: In the openhab server, upon event subscription in org.eclipse.smarthome.io.rest.sitemap.internal.SitemapResource, the injected javax.ws.rs.core.UriInfo assumes the HTTP protocol. Therefore openhab returns an HTTP url for the eventsource.

Solution
Following Kai’s pointer to Nginx with https as reverse proxy for openhab2, I made the reverse proxy tell openhab the protocol of the original request, namely HTTPS:

ProxyPass "/" "http://openhabianpi:8080/"
ProxyPassReverse "/" "http://openhabianpi:8080/"
RequestHeader set X-Forwarded-Proto "https" # <--- make openhab aware of HTTPS

Question
Why does openhab generate complete urls in org.eclipse.smarthome.io.rest.sitemap.internal.SitemapResource rather than only paths? Using paths the web application can assemble the correct event source url. Therefore proxy configuration would be simplified.

Regards and “Grüße aus Frankfurt”.

1 Like
5

bumping

6

I add the following to get around that:

ProxyPass /rest http://openhab:8080/rest
ProxyPass /basicui http://openhab:8080/basicui
ProxyPass /icon http://openhab:8080/icon
ProxyPass /chart http://openhab:8080/chart

This seems to be all of them :slight_smile: It would be nice if they were relative. I have the same problem on other apps so it is pretty common. Your RequestHeader directive works great to fix the protcol issue btw…

7

Very late reply to this chain, but I’m trying to cure the occasional “offline” error when accessing through nginx and this looks like the right place to start.

Am I right to think I end up with a rather clumsy set of nginx location settings like this:


server {
        listen                          446 ssl;
        server_name                     my.url.com;
        ssl_certificate                 /etc/letsencrypt/live/my.url.com/fullchain.pem;
        ssl_certificate_key             /etc/letsencrypt/live/my.url.com/privkey.pem;
        ssl_client_certificate          /home/dan/client-cert/ca.crt;
        ssl_verify_client on;
        add_header                      Strict-Transport-Security "max-age=31536000";



        location / {
                proxy_pass                            http://localhost:8080/;
                proxy_set_header Host                 $http_host;
                proxy_set_header X-Real-IP            $remote_addr;
                proxy_set_header X-Forwarded-For      $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto    "https";

        }

        location /rest {
                proxy_pass                            http://localhost:8080/rest;
                proxy_set_header Host                 $http_host;
                proxy_set_header X-Real-IP            $remote_addr;
                proxy_set_header X-Forwarded-For      $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto    "https";

        }

        location /basicui {
                proxy_pass                            http://localhost:8080/basicui;
                proxy_set_header Host                 $http_host;
                proxy_set_header X-Real-IP            $remote_addr;
                proxy_set_header X-Forwarded-For      $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto    "https";

        }

        location /icon {
                proxy_pass                            http://localhost:8080/icon;
                proxy_set_header Host                 $http_host;
                proxy_set_header X-Real-IP            $remote_addr;
                proxy_set_header X-Forwarded-For      $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto    "https";

        }

        location /chart {
                proxy_pass                            http://localhost:8080/chart;
                proxy_set_header Host                 $http_host;
                proxy_set_header X-Real-IP            $remote_addr;
                proxy_set_header X-Forwarded-For      $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto    "https";

        }




}

thanks,

Dan

1 Like
8

and I’ve added another clumsy chain for http://localhost:8080/proxy - otherwise proxied images cause the “offline” error

but surely there is a neater way to do this!

Dan