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.
ProxyPass / http://10.0.0.1:8080/
ProxyPassReverse / http://10.0.0.1:8080/
RequestHeader set X-Forwarded-Proto "https" env=HTTPS
AuthName "xyz.example.com 444 "
Allow from 10.0.0.0/255.255.255.0
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.
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
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.
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
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!!