openHAB 3 Apache Reverse Proxy setup issue

fifo · December 13, 2020, 11:21pm

First I’ll start by saying I have had the same apache setup for years now with it working perfectly till upgrading to OH3. When trying to access from an external location to my network either via the android app or a browser, I am getting invalid login issues. If I append the basicui/app to the end of the URL It seems to want to load but only partially loads the page. let’s assume my openHAB internal ip is 10.0.0.1 and I am using 444 as the external port on apache. Internal to my network it all works perfectly.

Here is my apache config.

<VirtualHost *:444>
        ServerName xyz.example.com
        SSLEngine on
        Include /etc/letsencrypt/options-ssl-apache.conf
        SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
        ProxyPreserveHost on
        ProxyPass      / http://10.0.0.1:8080/
        ProxyPassReverse / http://10.0.0.1:8080/
        RequestHeader set X-Forwarded-Proto "https" env=HTTPS
        <Location />
                AuthType Basic
                AuthName "xyz.example.com 444 "
                AuthUserFile /etc/apache2/.passwd
                Require valid-user
                Allow from 10.0.0.0/255.255.255.0
        </Location>
</VirtualHost>

if I go to http://10.0.0.1:8080/basicui/app internally it works as expected. Now if I go to https://xyz.example.com:444 It fails from the app and on a browser, if I go to https://xyz.example.com:444/basicui/app it halfway loads and seems to fail midway. I don’t see anything odd in my apache logs. It seems the new UI may have impacted the functionality. I tried playing around with the API Security and toggled allow basic authentication as well as the implicit user role options but it seems to have no effect. I imagine those options are for if you use openhab.org. Either way, not sure if anyone has any ideas I can try. My workaround now is just using OpenVPN but it’s an extra step or two to turn that on. I would rather use the reverse-proxy option as I have done previously.

Bruce_Osborne · December 13, 2020, 11:28pm

You might find some ideas in this NGINX thread.

EDIT This post looks like your answer.

fifo · December 14, 2020, 1:00am

@Bruce_Osborne that did the trick thank you… Here is the working config I have in case anyone runs into this in the future.

This particular config will use the passwords set in the .htpasswd file. Local access will bypass authentication but if you don’t want that you can remove the “Allow from” line.

<VirtualHost *:444>
        ServerName xyz.example.com
        SSLEngine on
        Include /etc/letsencrypt/options-ssl-apache.conf
        SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
        Header set Set-Cookie "X-OPENHAB-AUTH-HEADER=1"
        ProxyPreserveHost on
        ProxyPass      / http://10.0.0.1:8080/
        ProxyPassReverse http://10.0.0.1:8080/ /
        RequestHeader set X-Forwarded-Proto "https" env=HTTPS
  	Header add Authorization ""
  	RequestHeader set Authorization ""
        <Location />
                AuthType Basic
                AuthName "xyz.example.com 444 "
                AuthUserFile /etc/apache2/.passwd
                Require valid-user
                Allow from 10.0.0.0/255.255.255.0
        </Location>
</VirtualHost>

thicknesss · March 29, 2021, 11:27am

Thanks that helped me out.
If someone gets an error after restarting Apache2 (like I did) :
“Invalid command ‘Header’, perhaps misspelled or defined by a module not included in the server configuration”, then just run a2enmod headers to enable the mod_headers.
After that restart your Apache

marco_hoefle · November 21, 2021, 11:52am

Hello,
can someone confirm that it is still working with 3.1?
I am always getting an openhab login page in addition to the webserver login popup.
Thanks
Marco

fifo · November 21, 2021, 12:35pm

@marco_hoefle I can confirm that it is working for me and I am on the latest milestone build. Same config as above.

marco_hoefle · November 27, 2021, 9:23am

For any reason this didn’t work with LDAP. I was always asked for the admin after the browser/server login.
This is the configuration which works for me:

<VirtualHost *:80>
        ServerName myserver
        Redirect permanent / https://myserver
</VirtualHost>


<VirtualHost *:443>
        ServerName myserver

        Include /etc/apache2/sites-available/ssl_config.incl

        Header set Set-Cookie "X-OPENHAB-AUTH-HEADER=1"
        ProxyPass / http://172.17.0.1:8080/
        ProxyPassReverse http://172.17.0.1:8080/ /

        ProxyPreserveHost on

        RequestHeader unset Authorization

        <Location />
                AuthType Basic
                AuthName "dahoam"
                Include /etc/apache2/sites-available/ldap_config.incl
                Require ldap-group CN=...,CN=Users,DC=..,DC=..
        </Location>

        ErrorLog ${APACHE_LOG_DIR}/dahoam_error.log
        CustomLog ${APACHE_LOG_DIR}/dahoam_access.log combined
</VirtualHost>

FoxWhiskey · September 19, 2022, 2:48pm

I can also confirm that the approach(es) shown here are working!

However I notice different behaviour, depending on the following configuration suggestions:

With

Header add Authorization ""
RequestHeader set Authorization ""

set, a call to the vHost displays the login-window of openHAB - no preview page or any tabs are displayed…

If “RequestHeader unset Authorization” is set instead, the called website looks like expected (like a direct call to localhost:8080)

Also the session cookie seems to expire pretty fast - I’m not sure if this is somehow related to the reverse proxy mechanism. But it does not occur, when logging into localhost:8080

[WARN ] [.io.rest.auth.internal.TokenResource] - Not refreshing token for session 465db89d-x4c8-4xx1-xxxx-5xxxx2a5xxxx of user bernie, missing or invalid session cookie
[WARN ] [.io.rest.auth.internal.TokenResource] - Token issuing failed: invalid_grant

Does anyone have ideas why this could be the case and what to do?

Best regards
-bernie

DanielMalmgren · September 21, 2022, 8:51am

Well, for me the proxying doesn’t work much at all lately. The authentication works but OH just gives me a white page. There’s html, just nothing in the body. Anyone knows why that could be? It works fine when going directly on http port 8080.

FoxWhiskey · September 30, 2022, 5:51am

Well, hard to tell without any details! How did you set up your vhost ?

DanielMalmgren · October 1, 2022, 8:50am

Yes, of course. It thought it might be something more general. Anyway, now when I tried again I also took a look in my apache error log and it turned out the file containing the password simply didn’t exist anymore. No idea how that could have happened, but recreating it solved the problem

nikagl · October 10, 2022, 7:32am

FoxWhiskey:

Also the session cookie seems to expire pretty fast - I’m not sure if this is somehow related to the reverse proxy mechanism. But it does not occur, when logging into localhost:8080
[WARN ] [.io.rest.auth.internal.TokenResource] - Not refreshing token for session 465db89d-x4c8-4xx1-xxxx-5xxxx2a5xxxx of user bernie, missing or invalid session cookie
[WARN ] [.io.rest.auth.internal.TokenResource] - Token issuing failed: invalid_grant
Does anyone have ideas why this could be the case and what to do?

I seem to have exactly this issue. Same error messages in apache logs after it seems to end the session and I need to re-login.

After this happens, I get an additional logon screen too, which I do not know where it comes from?

Regards,

Nika.

FoxWhiskey · December 21, 2022, 12:40pm

During a system update a couple of days ago, OH 3.4.0 was deployed on my Debian 11 and I took the chance to take a closer look at the “expiring cookie problem” once more…

I opened two Firefox windows and logged in twice - One time using the “default” URL (http://default.url:8080) and a second time using the proxied URL (http://proxied.url/).

I’m not a very experienced web programmer, but fortunately Mozilla’s Web developer tool (F12) threw sufficient light on the problem: the reason for the session cookie to expire so fast is pretty straight forward: it simply does not exist !

Apparently the (Apache) server config line
Header set Set-Cookie "X-OPENHAB-AUTH-HEADER=1"
prevents OH to set the required session cookie of name X-OPENHAB-SESSIONID !!

So, I commented out the HEADER set directive and found that the problem no longer existed! I also played around with the other Authorization directives and found that they don’t seem to be necessary either - from what I have tested, at least.

To cut a long story short:
For HTTP use, delete following lines from the examples above:

Header set Set-Cookie "X-OPENHAB-AUTH-HEADER=1"
Header add Authorization ""
RequestHeader set Authorization ""

and reverse proxying should work as expected (OH 3.4.0 !!)

Note: I have not (yet) tested the config on HTTPS, though!!

Hope it helps!
-bernie