In my case I don’t wish to rate-limit specific api-endpoints though, I wish to rate limit requests to any page on the site, partitioned by the caller IP address,
How do I do this - and at the same time not rate-limit requests to the backoffice.
Have you explored things like Azure Frontdoor or putting Cloudflare in front of your site? I have mostly only experience with Cloudflare.
These are well established projects with years and years of experience in what works and doesn’t work and it’s just a joy to tap 1 toggle and have it all set up for you.
For example IP spoofing is easy, and that’s the thing other product have figure out how to detect and kill immediately.
Also, I’d take a step back and ask why do you want to rate limit by IP?
Unlike APIs, normal web pages shouldn’t be performing intensive or long running operations, so rate limiting doesn’t make sense in the same way. Especially considering that there are performance optimisations such as caching that would benefit all users of your site, rather than simply penalizing those that are deemed to be making too many requests.
IME, caching is a much better protection from things like DoS anyway - especially as the most common source of DoS “attacks” are my client’s successful marketing campaigns.
If you still want to go ahead with limiting by request rate then strictly speaking I’d say that rate limiting in this context is a webserver concern, specifically an edge-server concern. So if you’re using e.g. Cloudflare that’s the proper place to do it, if IIS is your edge server then better to configure rate limiting there.
Thanks for the comments. I don’t think I have access to the CloudFlare configuration or the Windows or IIS configuration in the Umbraco cloud installation. But if these are the correct ways of achieving this, then I wonder why the Umbraco docs don’t mention it, and instead describe ASP.NET Core middleware rate-limiting.
In any case I have found a solution which we will experiment with, supplying parameters allowing “reasonable use” of the website.
Because that would work on both IIS and other webservers (Linux for example).
Cloud has a (very) limited subset available, I am not sure what you’re trying to do and why but the advise would probably be to investigate using your own CF account in front of the Cloud site so you can configure what you want (can’t remember if this is possible but I think so) or maybe the Cloud support team can help you with your specific case, but generally, the only “specific” case I know is “I’m under attack, help”.
The docs are specifically talking about rate limiting API endpoints rather than web pages generally.
Rate limiting is a much more normal thing for public and/or private APIs. They don’t benefit from the kind of client caching that web pages and thier assets do. APIs are likely to be much more computationally expensive than fetching a simple web page. It’s also normal for have separate terms of service (tiered service levels, per-user billing etc.) than we’d expect from the open web.