Il modo migliore per implementare la limitazione delle richieste in ASP.NET MVC?

Stiamo sperimentando vari modi per limitare le azioni degli utenti in un determinato periodo di tempo :

  • Limita posti di domande / risposte
  • Limitazioni
  • Limitare i recuperi di mangimi

Per il momento, stiamo usando la Cache per inserire semplicemente un record dell’attività dell’utente – se quel record esiste se / quando l’utente fa la stessa attività, accelera.

L’uso della cache consente di eseguire automaticamente la pulizia dei dati e le windows di attività scorrevoli degli utenti, ma il modo in cui verrà ridimensionata potrebbe essere un problema.

Quali sono altri modi per garantire che le richieste / azioni dell’utente possano essere efficacemente limitate (enfasi sulla stabilità)?

    Ecco una versione generica di ciò che abbiamo utilizzato su Stack Overflow nell’ultimo anno:

    ///  /// Decorates any MVC route that needs to have client requests limited by time. ///  ///  /// Uses the current System.Web.Caching.Cache to store each client request to the decorated route. ///  [AttributeUsage(AttributeTargets.Method, AllowMultiple = false)] public class ThrottleAttribute : ActionFilterAttribute { ///  /// A unique name for this Throttle. ///  ///  /// We'll be inserting a Cache record based on this name and client IP, eg "Name-192.168.0.1" ///  public string Name { get; set; } ///  /// The number of seconds clients must wait before executing this decorated route again. ///  public int Seconds { get; set; } ///  /// A text message that will be sent to the client upon throttling. You can include the token {n} to /// show this.Seconds in the message, eg "Wait {n} seconds before trying again". ///  public string Message { get; set; } public override void OnActionExecuting(ActionExecutingContext c) { var key = string.Concat(Name, "-", c.HttpContext.Request.UserHostAddress); var allowExecute = false; if (HttpRuntime.Cache[key] == null) { HttpRuntime.Cache.Add(key, true, // is this the smallest data we can have? null, // no dependencies DateTime.Now.AddSeconds(Seconds), // absolute expiration Cache.NoSlidingExpiration, CacheItemPriority.Low, null); // no callback allowExecute = true; } if (!allowExecute) { if (String.IsNullOrEmpty(Message)) Message = "You may only perform this action every {n} seconds."; c.Result = new ContentResult { Content = Message.Replace("{n}", Seconds.ToString()) }; // see 409 - http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html c.HttpContext.Response.StatusCode = (int)HttpStatusCode.Conflict; } } } 

    Esempio di utilizzo:

     [Throttle(Name="TestThrottle", Message = "You must wait {n} seconds before accessing this url again.", Seconds = 5)] public ActionResult TestThrottle() { return Content("TestThrottle executed"); } 

    La cache di ASP.NET funziona come un campione qui: con l’uso, si ottiene la pulizia automatica delle voci di accelerazione. E con il nostro crescente traffico, non stiamo vedendo che questo è un problema sul server.

    Sentiti libero di dare un feedback su questo metodo; quando rendiamo migliore lo Stack Overflow, ottieni la tua correzione Ewok ancora più velocemente 🙂

    Microsoft ha una nuova estensione per IIS 7 chiamata Dynamic IP Restrictions Extension per IIS 7.0 – Beta.

    “Dynamic IP Restrictions per IIS 7.0 è un modulo che fornisce protezione contro attacchi denial of service e brute force su server Web e siti Web. Tale protezione viene fornita bloccando temporaneamente gli indirizzi IP dei client HTTP che generano un numero insolitamente elevato di richieste simultanee o che fanno un gran numero di richieste per un breve periodo di tempo. ” http://learn.iis.net/page.aspx/548/using-dynamic-ip-restrictions/

    Esempio:

    Se si impostano i criteri da bloccare dopo X requests in Y milliseconds o X concurrent connections in Y milliseconds l’indirizzo IP verrà bloccato per Y milliseconds quindi le richieste saranno nuovamente consentite.

    Usiamo la tecnica presa in prestito da questo URL http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx , non per la limitazione, ma per il Denial Of Service (DOS) di un uomo povero. Anche questo è basato sulla cache e potrebbe essere simile a quello che stai facendo. Stai rallentando per prevenire gli attacchi DOS? I router possono certamente essere usati per ridurre il DOS; pensi che un router possa gestire la limitazione di cui hai bisogno?