GitHub (and I think GitLab) allows uploading files to releases if you make an actual release out of a tag. Just wanted to mention that as a potential free mirror for the built release in lieu of downloads directly from your web server for the time being (it of course won't have differential upgrade support, but perhaps better than nothing).
I'll consider it, thank you. I had to do what I did last night in a moment's notice at 12 am because my server froze up. Therefore, I didn't have any time to implement convenient solutions; my only goal was to mitigate the problem so my server can stabilize.
I don't think that I am going to enable releases. The reason being is that I would have to change the development workflow of Composr CMS (e.g., the documentation) to account for it. I don't believe that is necessary for a temporary problem. Plus, GitHub/GitLab builds are not to be run on production (even tagged ones) because they also contain virtually all non-bundled addons; I would need to do special releases through the CI/CD pipeline, probably.
Also, you can basically do the same thing by going in the tags, clicking a tag, and cloning the repository from a given tag to a ZIP file.
I'm hoping that this will only last a few days. I am working with OVH on a more convenient and permanent solution.
I'm not talking about a different type of build that "contains virtually all non-bundled addons" or anything special with CI pipelines. I'm talking about dragging and dropping the ZIP file that would otherwise be hosted on this homesite, into the GitHub/GitLab release, so people can download it from there using GitHub/GitLab's bandwidth (and bot protection) rather than yours.
Suit yourself, though. I'll be interested to see what solution you come up with.
The primary problem, I believe, is the massive number of bots accessing composr.app. In the last month, the site received 3 million hits. This is wildly more than any other site on my server (and compo.sr).
Normally, my server could handle that just fine; despite the heavy number of requests, the CPU usage was still under 10%. And the memory use was fine. However, I noticed that Cloudflare was only serving about 1 GB of cached traffic. The other 230 GB of traffic was not cached. I believe the bots are trying to download stuff from the site and potentially using up my server's available bandwidth. And that is why everything slowed down.
However, there is a critical bug in the downloads system. I can't block guests from downloading stuff even if I set the permissions and privileges accordingly. Even an htaccess block did not work. I had no choice but to physically delete the dload.php script (for now) and replace it with a simple exit statement that prevents downloads from happening.
I also observed that only 134k of the 3 million requests were identified as AI. If this is accurate, then a Cloudflare AI crawler block would not resolve the issue; composr.app would still get 2.8 million requests.
I already have a rate limiter in place, so that is not the solution. These devices are accessing composr.app from a bunch of different IP addresses.
I can't keep JavaScript challenges enabled. These are very effective at stopping all of these requests. However, they break a lot of Composr's functionality (telemetry, AJAX, upgrade checks, RSS feeds, etc).
My options are very limited. Currently, I don't have a solution. But I'll be doing more investigation to see if I can figure something out.
I implemented global limits on my server (rate limit, download speed limit, persistent database connections). Unfortunately, the problem still persists when I disable Under Attack mode on Cloudflare. It looks like downloads are not the issue (but that is still a critical bug that I need to fix). It's simply my server getting overwhelmed.
Downloads are now enabled. However, strict rate limits and Cloudflare's "Under Attack" mode will remain active indefinitely. Unfortunately, these bots continue to overwhelm my server. I cannot implement a robust mitigation solution without paying more money for a Cloudflare upgrade or for an upgrade of my server.
I have "Under Attack" mode disabled for the API endpoints. Composr sites must be able to access them without the JavaScript challenge. Otherwise, you won't be able to download addons or check for updates. It appears that the server is fine with this; the traffic is not targeting these pages.
I also enabled the static cache for guests and bots.
News: Emergency security on composr.app
Due to bots significantly slowing down my server, temporary emergency features are active. Please read more.
I don't think that I am going to enable releases. The reason being is that I would have to change the development workflow of Composr CMS (e.g., the documentation) to account for it. I don't believe that is necessary for a temporary problem. Plus, GitHub/GitLab builds are not to be run on production (even tagged ones) because they also contain virtually all non-bundled addons; I would need to do special releases through the CI/CD pipeline, probably.
Also, you can basically do the same thing by going in the tags, clicking a tag, and cloning the repository from a given tag to a ZIP file.
I'm hoping that this will only last a few days. I am working with OVH on a more convenient and permanent solution.
Suit yourself, though. I'll be interested to see what solution you come up with.
Normally, my server could handle that just fine; despite the heavy number of requests, the CPU usage was still under 10%. And the memory use was fine. However, I noticed that Cloudflare was only serving about 1 GB of cached traffic. The other 230 GB of traffic was not cached. I believe the bots are trying to download stuff from the site and potentially using up my server's available bandwidth. And that is why everything slowed down.
However, there is a critical bug in the downloads system. I can't block guests from downloading stuff even if I set the permissions and privileges accordingly. Even an htaccess block did not work. I had no choice but to physically delete the dload.php script (for now) and replace it with a simple exit statement that prevents downloads from happening.
I also observed that only 134k of the 3 million requests were identified as AI. If this is accurate, then a Cloudflare AI crawler block would not resolve the issue; composr.app would still get 2.8 million requests.
I already have a rate limiter in place, so that is not the solution. These devices are accessing composr.app from a bunch of different IP addresses.
I can't keep JavaScript challenges enabled. These are very effective at stopping all of these requests. However, they break a lot of Composr's functionality (telemetry, AJAX, upgrade checks, RSS feeds, etc).
My options are very limited. Currently, I don't have a solution. But I'll be doing more investigation to see if I can figure something out.
I have "Under Attack" mode disabled for the API endpoints. Composr sites must be able to access them without the JavaScript challenge. Otherwise, you won't be able to download addons or check for updates. It appears that the server is fine with this; the traffic is not targeting these pages.
I also enabled the static cache for guests and bots.