Currently openhab seems to limit connections to the server to three connections per IP-address (browser, http connection).
When creating new widgets I often have all three connections open. As we start to deprecate and replace log viewer by an internal log viewer this would decrease my browser connections to two (plus the one for log viewer). I guess this will affect a few more user.
I can remember that there was a setting for this. Can anybody help?
1 Like
Could anybody please conirm if you have the same limitation (max. 3 open browser windows to openhab server?
i just like to know if it is just me or a general limitation.
Thanks
I can only use two browser tabs from the same machine. A third tab does nothing until another one is closed.
1 Like
I experience something similar, and the new log viewer will make this even more of a problem.
This limitation is not openHAB specific but a browser limitation.
With openHAB 4.3.1 we have reduced the problem by saving one SSE connection for most setups (no web audio, no Command Item), and we will enable HTTP/2 for the HTTPS port, which will disable these limits effectively.
For HTTP only I fear we cannot to much more than reducing SSE connections.
1 Like
The way the world of browser(s) work these days is really tragic. It’s basically completely dictated by a few large companies, and every other need is ignored. The reason for this limit isn’t the browser itself, but to “protect servers”. And they refuse to change it or even make it configurable, because sites might be DoS’ed (although it doesn’t protect against DDoS). So, in this case, it’s completely meaningless because OH (the server) would want more connections, but the browser “protects OH” against its will because…
I for one won’t enable HTTPS - the increasingly annoying number of hoops you have to jump through to “accept” a self-signed certificate is just not workable. Again, anything not of interest to the big companies is completely ignored - at the very least, private addresses should be excluded from this rule, as it’s probably impossible to get a “officially signed”/rented certificate for private addresses anyway - and you’d need one for each potential address. It’s just meaningless.
I don’t think “relying on HTTP/2 with HTTPS” for the future is a viable strategy. People will just find it too cumbersome, if not impossible, to use (I’m not sure all OS/browser combinations will even let you accept a self-signed certificate).
I know close to nothing about how this is all implemented in OH and thus what possible mitigations would be implementable - and I do get that it might be a larger undertaking - but I think that maybe this should be a long-term goal to get around somehow. This is already a problem even with very few tabs if the UI wants to expand what it does and needs more connections (like it needs for audio, Command Item).
According to this SO topic, the potential work-arounds are:
- Use more host names. By assigning ex.
www1.example.com,www2.example.comyou get new connections for each host name. This trick works in all browsers. Don’t forget to change the cookie domain to include the whole domain (example.com, notwww.example.com) - Use web sockets. Web sockets are not limited by these restrictions and more importantly they are not competing with the rest of your websites content.
- Reuse the same connection when you open new tabs/windows. If you have gathered all realtime communication logic to an object call Hub you can recall that object on all opened windows like this:
1 Isn’t possible since OH usually works directly with a local IP address (although, it might be that a different port might count as “a different host” so it would be possible to make some “hack” where OH serviced several ports, and you could get around it this way)
2 Sounds like a good solution to me, but is probably more work to implement in MainUI because there’s more “manual handling” with web sockets as far as I understand. The “corporate firewall” issue might also be a potential issue, although I don’t get why anybody would enable “heuristic packet inspection” in a firewall, since these things always seem to create much more problems than they solve.
3 Sounds like a good solution in several ways, but I don’t know if new limitations on cross-tab information flow has been introduced in the years since this was written. I mean, fundamentally, if it was possible to share this between all tabs, the OH server would have less to do, there would be less traffic - it just sounds more efficient. You wouldn’t need to stream the same events in parallel to multiple tabs. But, it might not be possible anymore, and it might not “be compatible” with the way MainUI does subscription (if there are lots of changes to what is subscribed to depending on where the user browses).
In addition, it’s “the most obvious” solution to me, multiplexing (as was mentioned in the GitHub issue), so that all subscriptions are handled in one SSE connection (per tab). That would at least allow 6 tabs, and not pose future limitations if more “subscription types” were desirable. I assume that the “server side” of the SSE is OH’s REST API…? If so, this might require some redesign of the logic on both sides (both in Core and MainUI) to allow everything to be done in one connection, but it’s hard to imagine that one connection should technically “be able” to carry everything needed? If a logic was written that did the “multiplexing” and “demultiplexing”, the rest of the code could still be written without taking this into account, and the “multiplexing logic” could even do “deduplication” if that were ever a relevant situation (i.e. that the UI could just subscribe without taking into consideration if the same thing was already subscribed to, since the “multiplexing logic” would keep a “reference count” and just add the new subscription to the existing one).
These ideas might be way off/impossible because I don’t know how this is actually implemented, I’m just throwing out what I can see as possible ways to handle it without doing the work of actually studying the details of how this is done. So, shoot me if I’m wasting anybody’s time, but just know that it’s not necessary to do a lot of explanation if something isn’t possible - I’m aware that I don’t have the full picture - think of them merely as ideas.
I have a single Let’s Encrypt certificate for *.lab.[mydomain] that points to my webserver’s local address so all my local only services (that need it - it’s certainly overkill for some things) can use https with a certificate. It’s not that difficult if you already have the basic dns stuff in place, and it’s probably not a bad idea in general to gently nudge OH users towards https.
Same to me, https is too complicated and it prevents that I can load images from my camera, which is a different domain and I would run into these CORS problems.
In terms of browser limitations I simply use both openhab server’s IP-addresse AND hostname. This doubles the total amount of connetions
That’s a good solution if you run a local DNS. It’s my assumption that most users will never do that though.
Sure - but it also adds a layer of security.
I have my own PKI running at home with my own CA so I can give all my servers and services a TLS certificate, but I agree that would be way out of scope for most users.
Just in case anyone wants to do this as well, I have build my PKI around OpenSSL with a simple bash script and some OpenSSL config: GitHub - florian-h05/pki.bash: A simple yet powerful public key infrastructure built around OpenSSL, providing TLS server authentication certificates and mTLS client authentication certificates.
Sharing one SSE connection for everything is even for single-tabs difficult to implement I think … but
This is the best and simplest solution I think … with Refactor websocket code to `$oh` namespace & Pass access token through header by florian-h05 · Pull Request #2907 · openhab/openhab-webui · GitHub I have already refactored the log viewers specific WS code to a generic API that can be used all around Main UI, we just need to add reconnection handling similarly to how it was done in Add a SSE reconnection mechanism by florian-h05 · Pull Request #1807 · openhab/openhab-webui · GitHub for SSE.
Wrt to the corporate firewall thing: IMO one who enables such stuff at home should also be able to take care of getting WebSockets running with it, and if Main UI switches to WebSocket I would tend to make configurable, so one could opt-in to use SSE instead of WS.
1 Like
That sounds like a great long-term way to handle it to me - I’m rooting for this approach 
I was thinking that maybe some people have a solution where they want to access their OH installation from work without using a VPN (I’m not saying it’s a good idea, I would never do it, but it’s not up to me to decide what people do) and that the corporate firewall at their workplace might block it, not that this would be caught by their own firewall. It could also be some “cloud OH” instance for all I know, my idea was just that if somebody wanted to access OH directly from the Internet in some way, and they happened to work somewhere where their employer had activated such “packet inspection”, it probably wouldn’t work - and that it might not be so obvious why it didn’t work. But, if the changes are small enough that it’s viable to maintain both connection types, that would of course be ideal.
1 Like