Possible Live Helper Chat 4.90 polling issue with /front/tabs/

[nootkan]

While upgrading from LHC 3.70 to 4.90, I ran into an intermittent problem where the admin interface would suddenly become inaccessible while an operator had open chats and was viewing another admin page such as System Update.

I traced the traffic and found that LHC 4.90 was requesting:

/index.php/site_admin/front/tabs/(id)/...

once every second.

In the 4.90 source this appears in:

design/defaulttheme/js/admin/src/components/DashboardChatTabs.js

The relevant code is essentially:

if (!document.getElementById('tabs') && !document.getElementById('views-home')) {
useInterval(() => {
if (!state.chats || state.chats.length == 0) {
return;
}

    axios.get(WWW_DIR_JAVASCRIPT + "front/tabs/(id)/" + getChatIds().join('/'));
}, 1000);

}

This means that when an operator has open chats but is on an admin page that does not contain the normal tabs or views-home elements, LHC polls the same /front/tabs/ URI every 1000 ms.

My Apache server uses mod_evasive with:

DOSPageCount 4
DOSPageInterval 2
DOSSiteCount 100
DOSSiteInterval 2
DOSBlockingPeriod 10

The access log showed the problem very clearly.

/front/tabs/(id)/18 returned 200 at:

16:23:46
16:23:47
16:23:48
16:23:49
16:23:50

and then immediately began failing at:

16:23:51
16:23:52

Apache simultaneously logged client denied by server configuration for the LHC admin requests. Other visitor/widget requests continued working, so this was isolated to the admin polling behavior.

I did not want to weaken mod_evasive globally, so as a test I changed only the LHC timer from:

1000 to: 3000

in DashboardChatTabs.js, and made the equivalent change in the compiled admin JS bundle.

After the change, the access log showed the /front/tabs/ requests consistently about 3 seconds apart:

17:33:18
17:33:21
17:33:24
17:33:27
17:33:30

and they remained 200 OK continuously for more than three minutes. The same successful 3-second pattern continued throughout the extended test.

No further Apache denial messages occurred during the test.

So the 1-second hard-coded /front/tabs/ polling interval appears capable of colliding with fairly normal mod_evasive configurations. Changing it to 3 seconds completely resolved the issue on my server without changing the server-wide security settings.

It might be worth making this polling interval configurable in admin or increasing the default from 1000 ms. The regular LHC message-sync interval is already configurable, but this particular React /front/tabs/ timer appears to be hard-coded.

Hope this helps.