Puts a cork in their requests
Ruby
Pull request Compare This branch is 3 commits ahead, 173 commits behind zendesk:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
lib
test
.document
.gemtest
.gitignore
LICENSE
README.rdoc
Rakefile
VERSION
prop.gemspec

README.rdoc

Prop

Prop is a simple gem for rate limiting requests of any kind. It allows you to configure hooks for registering certain actions, such that you can define thresholds, register usage and finally act on exceptions once thresholds get exceeded.

To get going with Prop you first define the read and write operations. These define how you write a registered request and how to read the number of requests for a given action. For example do something like the below in a Rails initializer:

Prop.read do |key|
  Rails.cache.read(key)
end

Prop.write do |key, value|
  Rails.cache.write(key, value)
end

You can choose to rely on a database or Moneta or Redis or whatever you'd like to use for transient storage. Prop does not do any sort of clean up of its key space, so you would have to implement that manually should you be using anything but an LRU cache.

Once the read and write operations are defined, you can optionally define some preconfigured default thresholds. If for example, you want to have a threshold on accepted emails per hour from a given user, you could define a threshold and interval (in seconds) for this like so:

Prop.defaults(:mails_per_hour, :threshold => 100, :interval => 1.hour)

You can now put the throttle to work with this values, by passing the “handle” to the respective methods in Prop:

# Throws Prop::RateLimitExceededError if the threshold/interval has been reached
Prop.throttle!(:mails_per_hour)

# Returns true if the threshold/interval has been reached
Prop.throttled?(:mails_per_hour)

# Sets the throttle "count" to 0
Prop.reset(:mails_per_hour)

# Returns the value of this throttle, usually a count, but see below for more
Prop.query(:mails_per_hour)

In many cases you will want to tie a specific key to a defined throttle, for example you can scope the throttling to a specific sender rather than running a global “mails per hour” throttle:

Prop.throttle!(:mails_per_hour, mail.from)
Prop.throttled?(:mails_per_hour, mail.from)
Prop.reset(:mails_per_hour, mail.from)
Prop.query(:mails_per_hour, mail.from)

The throttle scope can also be an array of values, e.g.:

Prop.throttle!(:mails_per_hour, [ account.id, mail.from ])

If the throttle! method gets called more than “threshold” times within “interval in seconds” for a given handle and key combination, Prop throws a Prop::RateLimitExceededError. This exception contains a “handle” reference, which is handy when you are using Prop in multiple locations and want to be able to differentiate further up the stack. For example, in Rails you can use this in e.g. ApplicationController:

THROTTLE_MESSAGES = Hash.new("Throttle exceeded")
THROTTLE_MESSAGES[:login] = "Too many invalid login attempts. Try again later."

rescue_from Prop::RateLimitExceededError do |exception|
  render :status => 403, :message => THROTTLE_MESSAGES[exception.handle]
end

You can chose to override the threshold for a given key:

Prop.throttle!(:mails_per_hour, mail.from, :threshold => account.mail_throttle_threshold)

When the threshold are invoked without argument, the key is nil and as such a scope of its own, i.e. these are equivalent:

Prop.throttle!(:mails_per_hour)
Prop.throttle!(:mails_per_hour, nil)

The default (and smallest possible) increment is 1, you can set that to any integer value using :increment which is handy for building time based throttles:

Prop.setup(:execute_time, :threshold => 10, :interval => 1.minute)
Prop.throttle!(:execute_time, account.id, :increment => (Benchmark.realtime { execute }).to_i)

How it works

Prop uses the interval to define a window of time using simple div arithmetic. This means that it's a worst case throttle that will allow up to 2 times the specified requests within the specified interval.

Note on Patches/Pull Requests

  • Fork the project.

  • Make your feature addition or bug fix.

  • Add tests for it. This is important so I don't break it in a future version unintentionally.

  • Commit, do not mess with rakefile, version, or history. (if you want to have your own version, that is fine but bump version in a commit by itself I can ignore when I pull)

  • Send me a pull request. Bonus points for topic branches.

Copyright

Copyright © 2010 Morten Primdahl. See LICENSE for details.