State refresh after changing an item

Apps & Services Android App
1

Hi all,

I set up a reverse proxy based on apache 2.4 which, after struggling with the config quite a long time, is working from the outside world by a public DNS server name as well as from the inside (LAN and local DNS server name).
There is only one annoying thing which I tracked down to a timeout after POST, when using the SSL encrypted remote access. When I change, for example, a dimmable light the actual setting is not shown in the app until the proxy timeout occurs or when I change view in the app. It works like a charm if I am logged in to my WLAN an the local server URL is used.

As the http and https reverse proxy both use the same backend address http://127.0.0.1:myOHport I was expecting both configurations to behave identically.

Comparing the apache logs only shows that the POST request, which sends the new setting to the item, returns immediately followed by a GET using http, while POST times out on HTTPS (or maybe the following GET which should fetch the new item state).

The local config looks like this

    <VirtualHost my.local.ip:80>
      ServerName my.local.servername
      ErrorLog /var/log/apache2/lerror.log
      CustomLog /var/log/apache2/access.log vhost_debug
      CustomLog /var/log/apache2/referer.log referer

      ProxyPass / http://127.0.0.1:8880/
      ProxyPassReverse / http://127.0.0.1:8880/

      <Location "/">
        AuthName openHAB
        AuthType Basic
        AuthBasicProvider file
        AuthUserFile /my/password/file

        <RequireAll>
          <RequireAny>
            Require ip my.local.net
          </RequireAny>

          <RequireAny>
            Require ip some.client.without.username
            Require ip other.client.without.username
            Require valid-user
          </RequireAny>
        </RequireAll>
      </Location>
    </VirtualHost>

The SSL config looks like this:

    <VirtualHost my.local.server.ip:443>
      ServerName my.public.servername
      ProxyPass / http://127.0.0.1:8880/
      ProxyPassReverse / http://127.0.0.1:8880/
      ProxyTimeout 30
      ProxyPreserveHost On
      SetEnv proxy-nokeepalive 1
      SSLProxyEngine on

      RequestHeader set X-Forwarded-Proto "https"
      Header edit Location ^http: https:

      ProxyHTMLEnable On
      LogLevel info
      ErrorLog /var/log/apache2/ssl_error.log
      CustomLog /var/log/apache2/ssl_access.log ssl_vhost_common
      CustomLog /var/log/apache2/ssl_referer.log referer

      SSLEngine On

      SSLCACertificateFile /my/ssl/cakey
      SSLCACertificatePath /my/ssl/cacrt
      SSLCertificateFile /my/openhab/serverkey
      SSLCertificateKeyFile /my/openhab/servercrt
      SSLCARevocationCheck chain  no_crl_for_cert_ok
      SSLCARevocationPath /my/ssl/crl
      SSLCipherSuite HIGH:!aNULL:!MD5

      <Location "/">
        AuthName openHAB
        AuthType Basic
        AuthBasicProvider file
        AuthUserFile /my/openhab/pwfile

        SSLVerifyClient require
        SSLVerifyDepth 1

        <RequireAny>
          Require ip my.local.net
          Require valid-user

          <RequireAll>
            Require expr %{SSL_CLIENT_S_DN_OU} == 'my client OU'
            Require expr %{SSL_CLIENT_S_DN_O} == 'my client O'
          </RequireAll>

          <RequireAny>
            Require expr %{SSL_CLIENT_S_DN_CN} == 'user1'
            Require expr %{SSL_CLIENT_S_DN_CN} == 'user2'
            Require expr %{SSL_CLIENT_S_DN_CN} == 'user3'
            Require expr %{SSL_CLIENT_S_DN_CN} == 'user4'
          </RequireAny>
        </RequireAny>
      </Location>
    </VirtualHost>

The Basic UI shows the same behaviour. The Classic UI works as expected. Paper UI shows the same behaviour on the first change, every change on the same item after that results in “Error 400: Bad request”.

Checking a heating control item I saw that somehow the character encoding might be broken.

openhab.log:

2019-12-04 15:09:04.198 [WARN ] [rest.core.internal.item.ItemResource] - Receive
d HTTP POST request at 'items/HeizkoerperAnbauKueche_4_SetTemperature' with an i
nvalid status value '18.9 °C'.
2019-12-04 15:14:35.447 [WARN ] [rest.core.internal.item.ItemResource] - Receive
d HTTP POST request at 'items/HeizkoerperAnbauKueche_4_SetTemperature' with an i
nvalid status value '19.1 °C'.
2

I guess it has to do with the rewriting but doubt anyone is willing to debug your httpd.conf.
Move to nginx. openHABian comes with a working version of that, including config.

3

I don’t think I need anyone to debug my apache config files. I maintain several apache servers and I am quite familiar with configuring apache servers. I posted my config because most of the time the first question is “can you post your config”.

Can anyone confirm that reverse proxying with ssl and client certificates works with nginx? Especially concerning remote access and automatic update of the item values?

BTW: Everything, along with many other things like radius auth, samba server, dlna server, firewall, proxy, etc., is running on openSuSE Leap.

4

Not sure what you refer to but openHABian deploys nginx to include LetsEncrypt certificates.
Many OH users including myself successfully use it.

5

I’m referring to the App settings “Fernzugriff (Remote Access?)” and “SSL-Client-Zertifikat (-certificate)”. I deploy my own client certificates from my own CA. I don’t need all the things openHABian deploys as I have most of the stuff up running for “ages”.

I would like to get a confirmation that running the App for Android, which accesses a reverse proxy based on nginx does not show the same behaviour that I described above.

6

Of course you do, but that’s no clear answer if you want help. Probably everybody of those to use nginx use it to get the app to access OH safely (which of course includes SSL thus a server cert).

But we’re not your vendor or personal support hotline that you may talk to in that manner.
Sit down on your four letters, implement it and see for yourself. If you are as proficient in that stuff as you claim then that should be a snap, shouldn’t it.

7

I thought that, like you said, many others use a nginx based solution and that the work had already been done many times before. As you use it too I would have thought it to be much easier if you just open the App or access your Paper UI from a remote site, change a setting and confirm, that the changes to the item are visualized immediately in the App or Paper UI. That, in addition, would confirm it to be an issue with Apache and make it worth the time and the work to set up nginx in parallel to Apache.

As you can imagine it’s not that easy to set up a new web server in parallel to a complex virtual server environment just to find out what many users already found out before. I’m not a big fan of ressource wasting.

I am completely aware that this is not a personal support hotline. But I thought asking for knowledge and have benefit from the experiences of other users was a main purpose of these communities.

1 Like
8

I still don’t understand what you mean. Unless you refer to some exotic app you didn’t name, you don’t use the app to access PaperUI. That you would use a browser for. Or wouldn’t do that at all from remote if you’re serious about security.

I assume you mean proxy as you wouldn’t need another OH to be the web server.
Guess what, it is easy. openHABian source is on Github, just fetch what you need of it.

9

Did you read and understand what the problem is? I tried to describe it in my first post in this thread. The official App as well as Paper UI and Basic UI show a similar (and faulty) behaviour in my configuration, while Classic UI works as expected.
So it should not matter if someone tries it out with the App, Paper UI or Basic UI. If one of those does not show the faulty behaviour this would be a valuable hint in the right direction.

No, I mean a web server as both, nginx and apache, are web servers with reverse proxy capability. And the first problem is that two web servers cannot listen on the same port on the same physical server. Second I have to open at least one non-standard port in my Router and in my firewall to gain access to a parallel nginx server instance from outside my LAN. All this with the risk of temporarily breaking access to the services running.
Third problem is “openHABian is restricted to Debian/Ubuntu based systems”. As stated above I have an openSuSE Leap based system. Porting to openSuSE would not be helpful in matters of time and result.

A simple “works as expected” or “same issues” from someone who has a working system up and running would still be much simpler. I understand that openHABian is very good if you setup a new system on a supported platform but it’s not the answer for my question.

10

I admit I had forgotten about when replying to the other post, but you were adding to the confusion by talking about PaperUI only in your next post, and PaperUI is wrong in the first place thus misleading anyway. You mustn’t use PaperUI for any user action such as to switch items. It’s an admin UI.

No, both are software. Apache is capable of providing both functions, to be a server and a proxy, but its server capabilities are NOT used in this context. The server is a jetty which is part of OH.
Meanwhile nginx can even not be setup to serve (AFAIK - I admit I haven’t checked lately).
So you meant to say a proxy then.

So what, use a different port then or bind them to a virtual IP.

So what ? Just do.

nginx is available as a SuSE package, too, and the config you can get to look up on openHABian repo on GitHub. Again, so what ?

The point is that if it had been a known problem unrelated to your specific proxying setup, this would have shown up much earlier for many users. It didn’t so it’s related to your setup.
And who do you expect to also have an Apache to have the same very specific configuration to do the URL proxy rewriting ?

1 Like
11

Another misunderstanding… I’m talking about a working openHABian/nginx based installation with SSL access. Maybe others don’t care if the change does not show up in UI as long as the changes are transmitted to the items. Maybe it’s a problem related to my special setup.
To find out I am asking if my problem does not show in a setup you recommend.

As there is a difference in behaviour in my special configuration concerning Classic UI vs. Basic/Paper UI the problem might as well be UI specific.

12

I usually don’t cite myself but here goes:

13

Well, can’t say anything against your logic…

Maybe I’ll find the time to setup and test everything against nginx. Should be faster than asking anyone with an already configured system to tap on a light switch and observe the behaviour.

14

This is something you can explore without extra setting up efforts. BasicUI and ClassicUI use very similar REST calls, unsurprising as they do essentially the same job. Can’t be much different.

15

No need. I just did and behavior is as expected. Light switches on, virtual switch display state changes.
No need for sarcasm either.

16

I already know the difference. Accessing my SSL secured webserver, which proxies the request to my 127.0.0.1 openhab instance:

  1. Classic UI - Heating Control - Button up
    New temperature is immediately shown in UI, command (according to events.log) is sent to item

  2. Basic UI - Heating Control - Button up
    Command (according to events.log) is sent to item, temperature in UI unchanged, after timeout (configured for the proxy) message on the bottom of the UI “Offline: waiting for connection”
    Message disappears (Basic UI online again), new temperature is shown (first change like this: “19,00 °C”, every other change correct)

Classic UI shows physically changed items immediately, Basic UI comes up with the bottom message every 30 seconds and then, after being online again, shows actual values.

17

Sorry, meant a dimmable light where % should change accordingly.

18

Same there.

Same there, no matter if BasicUI or app.
I have seen the browser failing to refresh at times, but that’s browser dependent and a page reload always does.

19

More surprisingly, when using a VPN connection and using the local webserver on port 80, which proxies to the same openhab instance at 127.0.0.1, Basic UI works as expected (as well as Paper UI and the App). No “Offline” messages at the bottom of the page, no “strange” characters in the values.

20

There’s a thread about ssl client cert and nginx: Using NGINX Reverse Proxy for client certificate authentication - start discussion

I guess you really want to have ssl client certs and not just username and password?