2

We have an API that is an interface to a huge database. We sell the access to it as a service, and our clients are then able to get the data.

However, one of our goals is to deny any bot that attempts to access our database faster than a regular user, limiting it to a few requests at once (ie. one per two second).

Currently I am using WebApiThrottle to do this, however I can't figure out how to just "slow down" the requests instead of returning the "Too many requests" error. For example, creating a queue of requests and using something like Thread.Sleep() on then to limit to one per second, or anything like that, instead of immediately returning an error, and actually returning valid data.

Is this a good practice? How can I achieve this?

Guilherme
  • 5,143
  • 5
  • 39
  • 60
  • 3
    "Is this a good practice?" Absolutely not, the entire reason you are throttling the usage is so you don't have too many resources tied up. If you start queuing requests you will quickly exhaust the resources of your webserver with connections that are in the queue waiting for results and opening yourself to DoS attacks. – Scott Chamberlain Mar 21 '17 at 21:49
  • possible duplicate of http://stackoverflow.com/questions/19452881/how-to-maintain-state-or-queue-of-requests-in-web-api – Adam Mar 21 '17 at 21:49
  • @ScottChamberlain just what i thought. However, our actual concern is to just limit the speed of access to our database without returning an error. We have some other services on Azure that blocks DoS attacks – Guilherme Mar 21 '17 at 22:00
  • @Adam Very close but don't really helps to solve my problem on slowing down the requests. Our API is versioned and it is on the third version, with lots of controllers in each. I actually was thinking in something like a MessageHandler to manage the entire API at once, or something like that. – Guilherme Mar 21 '17 at 22:06
  • If you want to stick with slowing down - I think easiest solution would be to use async action filter which will await Task.Delay(..) inside based on your throttling logic; thus you get IIS queueing for free and minimal code to write. – Lanorkin Mar 22 '17 at 06:56
  • This question is old, but did you ever find a solution? As Lanorkin mentioned Task.Delay() would work. –  Jan 03 '18 at 00:28
  • @EricS Yes. I rewrote the entire system in ASP.NET Core 2 (the reason is not related to this issue), but it turned out to be way easier to solve this problem there. I ended up creating a middleware with some funky code using ConcurrentQueue (per session) and... done – Guilherme Jan 03 '18 at 04:14

0 Answers0