MainUI Authentication Problems with more than one tab open

[binderth (Thomas Binder)]

@rlkoshak

But you can instead open the developer sidebar, search for “timer”, right click on one of the rules found to open it in a new tab, copy the text from that new tab, switch to the original tab and then paste.

My experience is, that using multiple tabs leads to problems with authentication and I have to restart the whole browser. Is there a way to avoid that?
So currently I work with two seperate browsers to achieve copying/pasting without having to navigate from one rule to another.

[rlkoshak (Rich Koshak)]

@binderth

My experience is, that using multiple tabs leads to problems with authentication and I have to restart the whole browser. Is there a way to avoid that?

I’ve never experienced that problem, so I can’t say one way or the other. I routinely have at least three tabs open to OH at the same time and have never had an authentication problem (Firefox and Brave Browser). I used to have problems caused by MainUI falsely thinking it needed to save something I’ve already saved, and I’d have to reload the page, but that hasn’t happened since I moved to 5.0 (at least not yet).

Do you have sandboxing or private browsing turned on or something like that? Maybe the tabs can’t share the authentication cookie.

[ErikDB (Erik)]

@binderth

My experience is, that using multiple tabs leads to problems

I don’t know the specifics, but that’s been discussed here some time ago, indeed (a year?). Too many tabs open makes them all unresponsive. I usually limit the amount of tabs to three.

[sihui]

@binderth

Is there a way to avoid that?

This does help for Firefox:

Tip if browser freezes due to too many http connections

A quick tip for anyone who’s having problems with openhab with the maximum number of HTTP connections in their browser (symptom: browser stops responding and needs to be restarted) and can’t or doesn’t want to use a reverse proxy: You can easily increase the number of connections in Firefox. To do this, enter about:config in the address bar, search for network.http.max-persistent-connections-per-server, and increase it (I use 12 without problems). On mobile devices the about:config options are…

[binderth (Thomas Binder)]

@ErikDB

I usually limit the amount of tabs to three.

@sihui

This does help for Firefox:

A quick tip for anyone who’s having problems with openhab with the maximum number of HTTP connections in their browser (symptom: browser stops responding and needs to be restarted) and can’t or doesn’t want to use a reverse proxy: You can easily increase the number of connections in Firefox. To do this, enter about:config in the address bar, search for network.http.max-persistent-connections-per-server, and increase it (I use 12 without problems). On mobile devices the about:config options are…

it’s not the amount of tabs or number of connections, I’m afraid:

• it’s not limited on one browser, every browser (edge, chrome, firefox) behave exactly the same
• it’s sometimes with two tabs open, sometimes immediately, sometimes after a few or a few more minutes

simply put: there’s no pattern for this, but it IS coming more sooner than later. What happens is, that lists (of items/things/rules…) won’t be shown anymore, if you’re in the middle of editing a rule, it won’t be saved anymore (only to find out after a few unsuccessful “saves” and finding out, the rule still fires with the old code)…

[sihui]

@binderth

What happens is, that lists (of items/things/rules…) won’t be shown anymore, if you’re in the middle of editing a rule, it won’t be saved anymore

I saw similar behaviour before I applied mentioned fix.
But I don’t use MainUI rules, though …

[binderth (Thomas Binder)]

@sihui

I saw similar behaviour before I applied mentioned fix.

it’s not the browser freezing over, it’s just the Main UI loses the connection to openHAB API. Sometime (not always) there’s a corresponding entry in the logs.

but perhaps we should split this thread and create a new topic for that behaviour? Some admin, please ?

edit:
I tried to replicate this right now.

first, the described behaviour sets in (I can’t see the lists anymore in the MainUI, but still can navigate aka lost connection)
after a while (not immediately) the following entries show up in the logs. I had five tabs open in one browser and two in another and both went unresponsive at different times. So these entries are more than tabs (perhaps requests?), and all at once:

2025-09-25 10:40:57.868 [WARN ] [openhab.core.io.rest.auth.AuthFilter] - Unauthorized API request from 192.168.78.230: Error while processing JWT token
2025-09-25 10:40:57.873 [WARN ] [openhab.core.io.rest.auth.AuthFilter] - Unauthorized API request from 192.168.78.230: Error while processing JWT token
2025-09-25 10:40:57.876 [WARN ] [openhab.core.io.rest.auth.AuthFilter] - Unauthorized API request from 192.168.78.230: Error while processing JWT token
2025-09-25 10:40:57.878 [WARN ] [openhab.core.io.rest.auth.AuthFilter] - Unauthorized API request from 192.168.78.230: Error while processing JWT token
2025-09-25 10:40:57.882 [WARN ] [openhab.core.io.rest.auth.AuthFilter] - Unauthorized API request from 192.168.78.230: Error while processing JWT token
2025-09-25 10:40:57.885 [WARN ] [openhab.core.io.rest.auth.AuthFilter] - Unauthorized API request from 192.168.78.230: Error while processing JWT token
2025-09-25 10:40:57.887 [WARN ] [openhab.core.io.rest.auth.AuthFilter] - Unauthorized API request from 192.168.78.230: Error while processing JWT token
2025-09-25 10:40:57.889 [WARN ] [openhab.core.io.rest.auth.AuthFilter] - Unauthorized API request from 192.168.78.230: Error while processing JWT token
2025-09-25 10:40:57.892 [WARN ] [openhab.core.io.rest.auth.AuthFilter] - Unauthorized API request from 192.168.78.230: Error while processing JWT token
2025-09-25 10:40:57.894 [WARN ] [openhab.core.io.rest.auth.AuthFilter] - Unauthorized API request from 192.168.78.230: Error while processing JWT token
2025-09-25 10:40:57.897 [WARN ] [openhab.core.io.rest.auth.AuthFilter] - Unauthorized API request from 192.168.78.230: Error while processing JWT token
2025-09-25 10:40:57.900 [WARN ] [openhab.core.io.rest.auth.AuthFilter] - Unauthorized API request from 192.168.78.230: Error while processing JWT token

[Larsen (Locke)]

… but you still didn’t try the fix by increasing the amount of connections?
Cause your symptoms are just what happens when you’re running out of connections. Give it a try.

[binderth (Thomas Binder)]

@Larsen

Cause your symptoms are just what happens when you’re running out of connections. Give it a try.

first off: my symptoms are what happens, when a headless frontend loses the authorization for the connection to the backend. (and I’m having usually like 20+ tabs open while working)
second: I tried jacking up the connections in firefox with no avail.

[florian-h05 (Florian H.)]

@binderth

first off: my symptoms are what happens, when a headless frontend loses the authorization for the connection to the backend.

What does the network tab say? Authorisation errors or requests that never complete?

[binderth (Thomas Binder)]

@florian-h05

What does the network tab say? Authorisation errors or requests that never complete?

That’s… great, that I didn’t think of that myself!

Just tried to replicate it. so after a while:

1. click on any navigation entry
2. “static” elements built themselves (images, css, …)
3. “REST API” elements won’t:

if you type in the IP/Port, the redirection to the /overview takes place, but also without REST API elements:

as you can see, the first request had almost 35secs for the answer, some elements are cached, but there’s also 200s on items directly from the webserver.

if I take an screenshot in between those 35secs you can see the “token”-request is the culprit:

In total that was 5/6 Tabs:

1. Transformations (read only),
2. scripts (one save action),
3. rules (multiple save actions),
4. another script (one save action),
5. API Explorer (only on GET /state on an item),
6. another rule with a save.
7. the other tab was the frontail for the logs (still using that, the built-in version is not useable for my cases).

btw: I still can use the browser with new tabs as I like. load local or remote hosts, do whatever I want. It is not a browser restriction, but a openHAB application restriction.

[florian-h05 (Florian H.)]

@binderth

I still can use the browser with new tabs as I like. load local or remote hosts, do whatever I want. It is not a browser restriction, but a openHAB application restriction.

@binderth

In total that was 5/6 Tabs:

It is the already mentioned browser restriction „max parallel HTTP connections per origin“.
Most modern browsers have 6 as the default limits, which corresponds to the 5/6 open tabs from the same origin.
The problem is, that each tab is maintaining a SSE connection to listen for Item state updates, so opening 6 tabs is basically taking all connections away from your pool of 6 and no more requests can be made, as long as you don‘t free a connection by closing a tab.

Pending requests that won‘t even start are basically the proof its a browser thing and no openHAB thing. If the request is submitted to the browser and not even initiated, we can do exactly nothing.

Static elements are served because they are either cached or loaded before the SSE/eventsource to events or states takes a connection.
The token request is very likely one of the first requests to be sent, and the UI waits for its completion before sending new requests. If the browser holds that request, we can only wait (forever in that case).

There are two things that can be done to fix this situation:

• You can switch to the integrated HTTPS on port 8443 where HTTP/2 is enabled, that will take away that limitation and allow for endless connections. (I know, kind of confusing its called HTTP connections, as HTTP is stateless and thereby connectionless.)
• We (developers) can switch from SSE to WebSocket for Item state updates, but openHAB Cloud currently doesn‘t support WS, so we need to use SSE there.

[binderth (Thomas Binder)]

Thanks. So I misinterpreted the “pending” stuff.

switching on SSL did indeed turn out to be the more stable, couldn’t replicate the behaviour since.
one thing I still find a bit odd: why is there (sometimes) WARN-messages in the log regarding failed authentication? like the ones above: Error while processing JWT token
ok, two things! closing a tab does not solve the problem, only a browser restart does. perhaps both “odd things” are connected…
(third thing would be, that all browsers can server other URLs even after broken openHAB)

[florian-h05 (Florian H.)]

@binderth

closing a tab does not solve the problem, only a browser restart does.

Closing more tabs?

@binderth

third thing would be, that all browsers can server other URLs even after broken openHAB

That’s normal. The limit is per origin, other servers are other origins.

[binderth (Thomas Binder)]

@florian-h05

Closing more tabs?

not quite. it works for “read only” tabs. if you opened random tabs and then ran into a problem, closing helps. But as long as you already saved something within some tabs (or perhaps that’s just coincidence?) only a complete browser close and restart helps.
of course it could be some other issue lays behind that behaviour, but just closing tabs doesn’t help in my use cases, when it builds up while I’m “real working” within the tabs

@florian-h05

That’s normal. The limit is per origin, other servers are other origins.

ah. ok!

[engine (Engineer)]

It seems that HTTP/2 is only possible if openHAB is directly loaded in the browser.

As I was annoyed by constant “no HTTPS” nagging from Firefox for my local services, I set up an nginx with a self-signed certificate. But the disadvantage is that only the connection from browser to nginx is HTTP/2. The connection from nginx to openHAB is only HTTP/1.1, because nginx doesn’t support HTTP/2 towards the backend.
With that I guess the 6 connections limit still applies. At least I also observe this issue from time to time.

But it’s not a problem tbh you just have to be aware of this restriction if using nginx.

[florian-h05 (Florian H.)]

@engine

The connection from nginx to openHAB is only HTTP/1.1, because nginx doesn’t support HTTP/2 towards the backend.

Nginx as reverse proxy has (by default, you can set a limit) no limit for the number of upstream connections.
See Module ngx_http_upstream_module.

From time to time the authorization can expire and I’m not sure the UI is able to handle this properly without a page reload.