OH3 with NGinx reverse proxy and Auth: blank page when reconnecting

Add-ons UIs
1

I’ve tried to find someone having the same problem, but, even if some are quite the same, the configuration are not exactly as mine.

Let me try to explain.
I’m using OH3.2 behind Nginx. I’m also using Vouch to provide SSO over different services (OH being one of them).

The configuration is pretty straightforward, nothing fancy I think.

Everything runs in its own Docker container, life is beautiful… except when my SSO token expires or if I logout (and invalidate it).

In this case, when I try to go back to OH, I can only see a blank page (black in my case as I use the dark theme).

Here is what can be observed in the dev tools:

image
image3232×556 126 KB

The problem is the same no matter what web browser is used (tried with Brave, Chrome, FF).

If I force reload the page, it works.

My NGinx configuration is rather (too?) simple:

map $http_upgrade $connection_upgrade {
        default upgrade;
        ''    close;
}

upstream openhab {
    server 192.168.0.10:9443;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name d*******************.info;

    access_log /var/log/nginx/openhab-access.log specialLog;
    include conf.d/include/ssl.inc;
    include conf.d/include/nginx-sso_auth.inc;

    large_client_header_buffers 10 512k;

    location / {
        auth_request_set $cookie $upstream_http_set_cookie;
        add_header Set-Cookie $cookie;

        auth_request_set $auth_resp_x_vouch_user $upstream_http_x_vouch_user;
        proxy_set_header X-Vouch-User $auth_resp_x_vouch_user;

        proxy_pass https://openhab/;

        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_set_header Upgrade                $http_upgrade;
        proxy_set_header Connection             "Upgrade";
        proxy_http_version                      1.1;

It’s quite easy to reproduce, considering Vouch, NGinx and OH are running together.

I’ve tried many different things (trying to force no cache on all resources for example, just to force something to be loaded everytime I access OH and be properly redirected to Vouch…) but nothing works.

It’s quite annoying (to say the least) since I’ve created a shortcut to OH on my Android phone, which just open a web browser empty shell to display my instance. Of course, as it’s an empty shell, there is no ‘reload’ button or whatever, so when the screen is black (Vouch token expired), it just doesn’t work…

Any help appreciated.

1 Like
2

I am not completely sure if it helps, but since your log provides a CORS error i wanted to share my additional headers, i am using for openHAB.

I am not using any sso service but had a (nearly) blank page problem too.
In my case only the sidebar and footer where rendered but nothing else.

I am not sure where i got those headers from exactly.
It was one of the many threads around here regarding nginx reverse proxy.
Those headers provide a pretty stable experience for me for some months now.

# 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;
3

I’ve tried your suggestions, but unfortunately, it didn’t work.

4

I got the same problem, but with a litte bit different configuration using keycloak / oauth2-proxy for authentification:

server {

  # Server config
  listen 443 ssl;
  server_name openhab.domain.de www.openhab.domain.de;

  # SSL Certs
  ssl_certificate /etc/letsencrypt/live/openhab.domain.de/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/openhab.domain.de/privkey.pem;

  #include ssl/ssl.conf;

  location  /oauth2/ {
    proxy_pass       http://auth.domain.de:1080;
    proxy_set_header Host                    $host;
    proxy_set_header X-Real-IP               $remote_addr;
    proxy_set_header X-Scheme                $scheme;
    proxy_set_header X-Auth-Request-Redirect $request_uri;
    # or, if you are handling multiple domains:
    #proxy_set_header X-Auth-Request-Redirect $scheme://$host$request_uri;
  }
  location  /oauth2/auth {
    proxy_pass       http://auth.domain.de:1080;
    proxy_set_header Host             $host;
    proxy_set_header X-Real-IP        $remote_addr;
    proxy_set_header X-Scheme         $scheme;
    # nginx auth_request includes headers but not body
    proxy_set_header Content-Length   "";
    proxy_pass_request_body           off;
    proxy_set_header X-Auth-Request-Redirect $request_uri;
    #set $args $args&allowed_groups=/ldap/openhab;
  }

  location / {
    proxy_pass https://192.168.10.165:8443/$request_uri;

    auth_request /oauth2/auth;
    error_page 401 = /oauth2/sign_in?rd=https://openhab.domain.de;
    #error_page 401 = /oauth2/start;

    # pass information via X-User and X-Email headers to backend,
    # requires running with --set-xauthrequest flag
    auth_request_set $user   $upstream_http_x_auth_request_user;
    auth_request_set $email  $upstream_http_x_auth_request_email;
    proxy_set_header X-User  $user;
    proxy_set_header X-Email $email;

    # if you enabled --pass-access-token, this will pass the token to the backend
    auth_request_set $token  $upstream_http_x_auth_request_access_token;
    proxy_set_header X-Access-Token $token;

    # if you enabled --cookie-refresh, this is needed for it to work with auth_request
    auth_request_set $auth_cookie $upstream_http_set_cookie;
    add_header Set-Cookie $auth_cookie;
    # When using the --set-authorization-header flag, some provider's cookies can exceed the 4kb
    # limit and so the OAuth2 Proxy splits these into multiple parts.
    # Nginx normally only copies the first `Set-Cookie` header from the auth_request to the response,
    # so if your cookies are larger than 4kb, you will need to extract additional cookies manually.
    auth_request_set $auth_cookie_name_upstream_1 $upstream_cookie_auth_cookie_name_1;

    # Extract the Cookie attributes from the first Set-Cookie header and append them
    # to the second part ($upstream_cookie_* variables only contain the raw cookie content)
    if ($auth_cookie ~* "(; .*)") {
        set $auth_cookie_name_0 $auth_cookie;
        set $auth_cookie_name_1 "auth_cookie_name_1=$auth_cookie_name_upstream_1$1";
    }

    # Send both Set-Cookie headers now if there was a second part
    if ($auth_cookie_name_upstream_1) {
        add_header Set-Cookie $auth_cookie_name_0;
        add_header Set-Cookie $auth_cookie_name_1;
    }

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

  }
}