You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pages such as search, export and exportview can be quite processor intensive. If these come under a DDoS attack then it can prevent other users from accessing all pages. Rate limiting access to these pages would reduce the chances of a successful DDoS attack.
When a request is made to one of these pages after the limit is reached is should return a 503 temporarily unavailable should be returned. This will require creating a static page that can be served with this response.
Storing a log of requests to rate limited pages so the frequency of recent access can be calculated needs to be separate from the database, as often DDoS attacks hammer the database and so relying on this would be unwise. A single file storing request and time could work but would need flock to make sure only one process can write to it at a time, where it would add the latest request and remove older requests outside a specified time frame.
In the configuration there should be an array or pages that would be included in the rate limit count, a timeframe to count requests over and a maximum number of requests (for any of the pages) in that time frame.
The text was updated successfully, but these errors were encountered:
Pages such as search, export and exportview can be quite processor intensive. If these come under a DDoS attack then it can prevent other users from accessing all pages. Rate limiting access to these pages would reduce the chances of a successful DDoS attack.
When a request is made to one of these pages after the limit is reached is should return a 503 temporarily unavailable should be returned. This will require creating a static page that can be served with this response.
Storing a log of requests to rate limited pages so the frequency of recent access can be calculated needs to be separate from the database, as often DDoS attacks hammer the database and so relying on this would be unwise. A single file storing request and time could work but would need flock to make sure only one process can write to it at a time, where it would add the latest request and remove older requests outside a specified time frame.
In the configuration there should be an array or pages that would be included in the rate limit count, a timeframe to count requests over and a maximum number of requests (for any of the pages) in that time frame.
The text was updated successfully, but these errors were encountered: