go-chi / httprate Goto Github PK

net/http rate limiter middleware

License: MIT License

Go 100.00%

httprate's Introduction

httprate

net/http request rate limiter based on the Sliding Window Counter pattern inspired by CloudFlare https://blog.cloudflare.com/counting-things-a-lot-of-different-things/.

The sliding window counter pattern is accurate, smooths traffic and offers a simple counter design to share a rate-limit among a cluster of servers. For example, if you'd like to use redis to coordinate a rate-limit across a group of microservices you just need to implement the httprate.LimitCounter interface to support an atomic increment and get.

Example

package main

import (
  "net/http"

  "github.com/go-chi/chi/v5"
  "github.com/go-chi/chi/v5/middleware"
  "github.com/go-chi/httprate"
)

func main() {
  r := chi.NewRouter()
  r.Use(middleware.Logger)

  // Enable httprate request limiter of 100 requests per minute.
  //
  // In the code example below, rate-limiting is bound to the request IP address
  // via the LimitByIP middleware handler.
  //
  // To have a single rate-limiter for all requests, use httprate.LimitAll(..).
  //
  // Please see _example/main.go for other more, or read the library code.
  r.Use(httprate.LimitByIP(100, 1*time.Minute))

  r.Get("/", func(w http.ResponseWriter, r *http.Request) {
    w.Write([]byte("."))
  })

  http.ListenAndServe(":3333", r)
}

Common use cases

Rate limit by IP and URL path (aka endpoint)

  r.Use(httprate.Limit(
  	10,             // requests
  	10*time.Second, // per duration
  	httprate.WithKeyFuncs(httprate.KeyByIP, httprate.KeyByEndpoint),
  ))

Rate limit by arbitrary keys

  r.Use(httprate.Limit(
    100,           // requests
    1*time.Minute, // per duration
    // an oversimplified example of rate limiting by a custom header
    httprate.WithKeyFuncs(func(r *http.Request) (string, error) {
    	return r.Header.Get("X-Access-Token"), nil
    }),
  ))

Send specific response for rate limited requests

  r.Use(httprate.Limit(
    10,            // requests
    1*time.Second, // per duration
    httprate.WithLimitHandler(func(w http.ResponseWriter, r *http.Request) {
      http.Error(w, "some specific response here", http.StatusTooManyRequests)
    }),
  ))

Related packages

Redis backend for httprate: https://github.com/go-chi/httprate-redis

LICENSE

MIT

httprate's People

Contributors

Stargazers

Watchers

Forkers

coraxster timbunce yaronius isgasho nothinux rizalgowandy adam-p missinglink creack 4cecoder bmharper zllovesuki nickspring yin-zt klaidliadon lukasjenicek bendrucker

httprate's Issues

Custom limit handling

So far this middleware doesn't allow for custom limit handling like changing the response body and code, additional logging etc. Some other tools like https://github.com/didip/tollbooth have this feature. I think it would be nice to add it here. I can come up with a PR if the idea doesn't sound bad.

P.S. And thanks for the great work on Chi!

Rate limit only on failed requests.

Is there an easy way to use the existing httprate functionality but push it to the end resolution of the request/response chain instead of at the beginning.

We want to create a couple of open ended mutation endpoints that could be used maliciously so we want to limit the total number of bad requests in a short period of time, but not limit penalize a user who is submitted good data that returns 2XX responses.

Pass windowLength to LimitCounter.Increment()

LimitCounter requireswindowLength to determine whether to evict the key expired. The external counter implementation needs to hold the same duplicatewindowLength as the Limit(_ , windowLength)

Cache burst issue

Hi,

We were testing this library for use as we already use Chi and found an issue with the current implementation.

Currently's it first checks the status and then increments. This will create an error in the following scenario which can be replicated with a unit test.

If the request limit is say 25/sec If I get 50 requests simultaneously in the first second then it will let them through as for every request the initial value will be 0.

Instead, if we can have a way in which the current window can be incremented and retrieved along with the previous window then this can be fixed.

type LimitCounter interface {
    // IncrAndGet is an atomic operation
    IncrAndGet(key string, inc time.Time, get time.Time) (inc int64, get int64, err error)
}

We wanted to use Redis and the example which I stated is doable using INCR command.

Please let me know your thoughts.