Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Notification icons crash and remain red due to server protection #38001

Closed
nikosdion opened this issue Jun 7, 2022 · 8 comments
Closed

Notification icons crash and remain red due to server protection #38001

nikosdion opened this issue Jun 7, 2022 · 8 comments

Comments

@nikosdion
Copy link
Contributor

See this post in the Facebook user group for details: https://www.facebook.com/groups/joomlanospam/permalink/10158355853635997/

Tagging @richard67

Steps to reproduce the issue

  • Use a live host which has some sort of anti-DoS protection. This is the tricky bit...
  • Install Joomla 4
  • Go to the administrator main page

Expected result

The notification icons are all green.

Actual result

Some or all of the notification icons remain red.

System information (as much as possible)

You need a live host which has some sort of anti-DoS protection and your Internet connection needs to be fast enough to trigger it.

Additional comments

This is the same problem I described in #37911 under “Batch update checks”.

Each one of the notification icons uses Joomla.Request to run an XMLHttpRequest on the server to retrieve the status of the icon. If the request fails with a server error the icon stays red.

The problem is that all of these icons try to send the request at the same time. From the server's point of view this looks like a Denial of Service attack. As a result the requests are blocked on most live servers (e.g. cPanel-based servers with mod_bw if I recall the name of the Apache module correctly). In some servers the user's IP is temporarily blocked.

The solution for this is a bit more complicated than what I did in my Joomla! Update PR #37911. Since each of these icons is its own plugin we can't magically batch them, nor is it desirable. Each update check may take a lot of time that combining them in a single request would cause a server timeout.

The solution is to handle these requests the same way I am handling multiple requests in Akeeba Backup's database and filesystem filter pages: a FIFO buffer.

We can add a new option to Joomla.Request, let's call it fifo. If it's true the request is added to a FIFO buffer. If the FIFO buffer was previously empty, Joomla.Request fetches and executes the first request in the FIFO buffer. Upon conclusion (successful return or error) it calls the handler code for that request and then repeats the FIFO fetch until there are no more requests in the FIFO buffer.

This is not perfectly bulletproof (bulletproofing it would require installing a timer triggering every 0.1s) but it's workable. In the use case described in this issue we'd never get concurrent requests. In case we had several asynchronous JS threads (timers) we might indeed get multiple requests but I think it's safe to say that this is not a use case Joomla.Request was made to handle anyway.

@richard67
Copy link
Member

I remember having seen this issue being reported somewhere else before, but I don't remember where it was, if earlier of facebook or in the support forum or here on GitHub ... but I haven't found anything here.

Could be hard to find people who have the right environment for testing a fix.

The idea with the new FIFO buffer sounds reasonable to me.

@nikosdion
Copy link
Contributor Author

@richard67 Several of my users have reported it to me, thinking it's Admin Tools somehow blocking the request but we could verify this happens with Admin Tools completely uninstalled and the .htaccess reverted to default. I swear I have also seen it at least once in the Joomla forum but it was on accident looking for something else. In any case, it's a pretty simple reason with a reasonable fix. I am working on another PR now. When I get some time, possibly later today or tomorrow, I'll submit a PR for this too.

@alikon
Copy link
Contributor

alikon commented Jun 7, 2022

i've got that problem sporadically using docker under windows

@nikosdion
Copy link
Contributor Author

I have made the pull request #38019 to address this.

It's not a perfect solution. Ideally we'd need to have configurable limits on the maximum number of requests per certain amount of time and the minimum time between requests. However, this would have made the QuickIcons appear sluggish for everyone. With my solution the majority of servers which had a problem will now work.

@alikon
Copy link
Contributor

alikon commented Jun 9, 2022

please test #38019

@alikon alikon closed this as completed Jun 9, 2022
roland-d pushed a commit that referenced this issue Jun 12, 2022
* Enqueue requests made from QuickIcon plugins

Fix for gh-38001

* Also enqueue requests made be AJAX badges

AJAX badges appear in custom dashboards rendered by
com_cpanel, e.g. the System Dashboard.
@jobrusche
Copy link

Although it is closed, this is still an issue in Joomla 4.2.6


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/38001.

@richard67
Copy link
Member

Although it is closed, this is still an issue in Joomla 4.2.6

@jobrusche It's a different issue which you have observed. This issue and the pull request #38019 are dealing with server protection against DoS being triggered by too many requests. Your issue #39674 seems to be caused by a CORS policy, see the comments there. Both issues share a symptom - red quickicons - but have completely different reasons.

@vishwakarmaashutosh
Copy link

Hi,

I have also faced this issue with the latest Joomla version(‎4.3.3). After doing some investigation I have just found a little solution. I have just added the correct URL( which runs on the browser ) of the site in configuration.php in the live site URL section and the issue has been resolved for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants