NGINX problem die to hue emulation

Hi,
I am using OH3 on a Raspi 3b and would like to use hue Emulation to control openhab via Alexa without using a cloud (so stay only local).

As my devices were not found I configurated my NGINX as follows

##################################
# openHABian NGINX Configuration #
##################################
server {
    listen 80;
     server_name localhost;

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      $scheme;
  }

location /api {
#      proxy_pass http://192.168.1.100:8080/api/;
      proxy_pass http://localhost:8080/api/;
    }

    return 301 https://$server_name$request_uri;

}
server {
    listen 443 ssl;
    server_name localhost;

    # Cross-Origin Resource Sharing.
    add_header 'Access-Control-Allow-Origin' '*' always;
    add_header 'Access-Control-Allow_Credentials' 'true' always;
    add_header 'Access-Control-Allow-Headers' 
'Authorization,Accept,Origin,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range' 
always;
    add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS,PUT,DELETE,PATCH' always;
    # openHAB 3 api authentication
    add_header Set-Cookie X-OPENHAB-AUTH-HEADER=1;
   
## Secure Certificate Locations
   ssl_certificate /etc/ssl/certs/openhab.crt;
   ssl_certificate_key /etc/ssl/certs/openhab.key;
    add_header Strict-Transport-Security "max-age=31536000"; # Remove if using self-signed and are having trouble.
    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 $scheme;
        proxy_read_timeout 3600;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Authorization "";
        satisfy any;
        allow 192.168.0.0/24;
        allow 127.0.0.1;
        deny all;
## Password Protection
#       auth_basic "Username and Password Required";
#       auth_basic_user_file /etc/nginx/.htpasswd;
    }
## Let's Encrypt webroot location
#WEBROOT location /.well-known/acme-challenge/ { WEBROOT root /var/www/localhost; WEBROOT }
}
# vim: filetype=conf

So far so good.
After deleting all Alexa devices and researching them, they also were found, but I am still not able to control them. Alexa says “device does not reply” resp. in the app “device unreachable” (hope that’s the correct translation for “das Gerät antwortet nicht” resp. “Gerät reagiert nicht”)

As far as I can see is the problem that all my requests from http://MyOhIp:80 are forwarded to https://localhost, and then nothing else happened, as on this device (laptop, mobile phone etc.) no openhab server is running.

Via Hue Essentials app also the devices and the emulated server is found, but when a device is switched I get the failure

"Unhandeled redirect: […] Status: 301 Moved Permanently. […] Nginx/1.10.3,
Which means as far as I can say also that there is a issue with the redirect.

I also tried to replace all “localhost” inside the NGINX with the IP of my Raspi, but unfortunately also without success…

I hope someone can help my out as I am really stucked at this point and am unable to solve the issue on my own :sweat::disappointed_relieved:

Thanks in advance,
Edizius

I am not sure if this will help nevertheless I would try:

  • in first server section only use return 301 and move the location items to the 443 section
  • server_name in server section ( listen 80 ) then needs to be the name resp. IP of the server
  • return 301 if returned to browser or any other host than the one nginx is running not has not to contain localhost
  • what is the behavior after these changes ?

Hi there,
first of all thanks for the reply and the support.
I tried to sharing the “listen 80” section, and put all into the rrt section as follows:

> ##################################
> # openHABian NGINX Configuration #
> ##################################
> server {
>     listen 80;
> #    listen 80  default default_server;
> 
>     server_name _;
> 
>     return 301 https://192.168.0.10:8443$request_uri;
> 
> }
> 
> server {
>     listen 443 ssl default default_server;
>     server_name 192.168.0.10;
> 
>     # Cross-Origin Resource Sharing.
>     add_header 'Access-Control-Allow-Origin' '*' always;
>     add_header 'Access-Control-Allow_Credentials' 'true' always;
>     add_header 'Access-Control-Allow-Headers' 
> 'Authorization,Accept,Origin,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range' 
> always;
>     add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS,PUT,DELETE,PATCH' always;
>     # openHAB 3 api authentication
>     add_header Set-Cookie X-OPENHAB-AUTH-HEADER=1;
>    
> ## Secure Certificate Locations
>    ssl_certificate /etc/ssl/certs/openhab.crt;
>    ssl_certificate_key /etc/ssl/certs/openhab.key;
>     add_header Strict-Transport-Security "max-age=31536000"; # Remove if using self-signed and are having trouble.
>     location / {
>        proxy_pass https://192.168.0.10:8443/;
>        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 $scheme;
>         proxy_read_timeout 3600;
>         proxy_set_header Upgrade $http_upgrade;
>         proxy_set_header Connection "Upgrade";
>         proxy_set_header Authorization "";
>         satisfy any;
>         allow 192.168.0.0/24;
>         allow 127.0.0.1;
>         deny all;
> ## Password Protection
> #       auth_basic "Username and Password Required";
> #       auth_basic_user_file /etc/nginx/.htpasswd;
>     }
> #location /api {
> #      proxy_pass https://192.168.0.10:8443/api/;
> #    }
> ## Let's Encrypt webroot location
> #WEBROOT location /.well-known/acme-challenge/ { WEBROOT root /var/www/localhost; WEBROOT }
> }
> # vim: filetype=conf

“location /api” was prev. not commented out, but I think this is the malicious part, because all pages with port 80 are fine except the /api pages, meaning e.g. page http://192.168.0.10:80/#!/settings/ is forwarded to https://192.168.0.10/#!/settings/ while http://192.168.0.10:80/api/status is forwarded to https://localhost/api/status.

I further found out that :8080 is not forwarded to HTTPS, but all works fine (no forward to localhost resp. better say no forward at all → http://192.168.0.10:8080/#!/settings/ keeps http://192.168.0.10:8080/#!/settings/)

By the way: I removed the specification of the hue IP and port in the openhab settings page.

Now with hue Essentials the lamps can be switched, but Alexa says still “no answer from device” (also after removing all devices and finding them again)

Best regards,
Edizius

P.S.:
New finding: it seems as all hue pages lead to a wrong forwarding, be because
http://192.168.0.10:80/description.xml is also forwarded to https://localhost/description.xml
→ maybe a problem of the hue binding, and not the NGINX, as “normal” pages are forwarded correctly?

P.P.S:
Uninstalled hue binding and page http://192.168.0.10:8080/description.xml results in
HTTP ERROR 404
Problem accessing /description.xml. Reason:

Not Found

While http://192.168.0.10:80/description.xml still leads to a forwarding to https://localhost/description.xml, so either it is not the hue emulations fault, or installation of the add-on is only partially done

Hi,
problem seems to be from Chrome browser as redirect in opera works, but claims that certificate is from a untrusted authority (openhab.org)
But, question is still how to solve the issue as Alexa still claims that the devices are unreachable. I assume there should be an exception for :80 to still use http instead of https (in opera is forwarded to https://192.168.0.10:8443)

Reachability test from 192.168.0.10:8080/api/status says by the way
URL Responds? Ours?
http://192.168.0.10:8080/description.xml yes yes
http://192.168.0.10/description.xml no no

So maybe also a problem that pages without port specified are forwarded to HTTPS? (In chrome http://192.168.0.10/description.xml is forwarded to https://localhost/description.xml and in opera to https://192.168.0.10:8443/description.xml

Pages without a port ( http://…/ ) means port 80.
According to your nxingx configuration all port 80 requests are forwarded ( 301 moved temporarily ) to https:…:8443 ).
To have a browser dependent forwarding you would have to check for the user agent in your nginx config. That seems not to be the case thus there is no browser dependent forwarding. So the browser itself must do something different with the URL. I think to remember that some browsers implemented something like HTTPS-Everywhere. This means the browser tries to replace http protocol with https protocol on it’s own before accessing a page using http protocol.

Ok, so Problem seems to be that hue emulation needs to be used on port 80 (at least for Alexa), which means http (and not HTTPS), and NGINX forwards all http requests to HTTPS, and thus, is not working?
→ only port 80 (and 8080?) Should stay http and all other should use 8443?
If so, how this has to be done?

Seems as I’ve been able to fix the fragile system.

  1. use in section 80 no 301 forward, but only the sections from hue emulation manual.
    →
server {
    listen 80;

location /api {
      proxy_pass http://192.168.0.10:8080/api/;
    }

location / {
    proxy_pass                              http://192.168.0.10: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      $scheme;
  }
}
  1. in 443 section all the stuff can be as desired (I think)
  2. set in hue emulation settings page port to 80 (IP I kept empty, and hue v1 emulation I also left deactivated)
  3. remove from alexa-homepage all smart home devices and search again
  4. call page http://192.168.0.10:8080/api/status/link (or however the IP of the Raspi is) to activate device pairing
  5. all devices were found on my side.

By the way: all entries in http://192.168.0.10/api/status were “no” but pairing still succeeded fine, and
Hue Pages with :80 are still forwarded to https://localhost by chrome (and :8443 by opera) but anyhow all seems to work is fine.

1 Like