-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Comments
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. |
@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. |
i've got that problem sporadically using docker under windows |
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. |
please test #38019 |
* 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.
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. |
@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. |
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. |
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
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 itfifo
. 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.
The text was updated successfully, but these errors were encountered: