mirror of
https://github.com/samsonjs/rack-attack.git
synced 2026-03-25 09:25:49 +00:00
version 2.3.0, update changelog, copy tweaks
This commit is contained in:
parent
b7ebb58bd9
commit
1d367f5acd
4 changed files with 10 additions and 7 deletions
|
|
@ -1,5 +1,8 @@
|
|||
# Changlog
|
||||
|
||||
## v2.3.0 - unlreleased (master)
|
||||
* Allow throttle `limit` argument to be a proc. (thanks @lunks)
|
||||
|
||||
## v2.2.1 - 13 August 2013
|
||||
* Add license to gemspec
|
||||
* Support ruby version 1.9.2
|
||||
|
|
|
|||
10
README.md
10
README.md
|
|
@ -78,7 +78,7 @@ The algorithm is actually more concise in code: See [Rack::Attack.call](https://
|
|||
|
||||
## Usage
|
||||
|
||||
Define whitelists, blacklists, throttles, and tracks as blocks that return truthy values if matched, falsy otherwise. In a Rails app
|
||||
Define whitelists, blacklists, throttles, and tracks as blocks that return truthy values if matched, falsy otherwise. In a Rails app
|
||||
these go in an initializer in `config/initializers/`.
|
||||
A [Rack::Request](http://rack.rubyforge.org/doc/classes/Rack/Request.html) object is passed to the block (named 'req' in the examples).
|
||||
|
||||
|
|
@ -150,7 +150,7 @@ how the parameters work.
|
|||
|
||||
# You can also set a limit using a proc instead of a number. For
|
||||
# instance, after Rack::Auth::Basic has authenticated the user:
|
||||
limit_based_on_proc = proc {|req| req.env["REMOTE_USER"] == "god" ? 100 : 1}
|
||||
limit_based_on_proc = proc {|req| req.env["REMOTE_USER"] == "admin" ? 100 : 1}
|
||||
Rack::Attack.throttle('req/ip', :limit => limit_based_on_proc, :period => 1.second) do |req|
|
||||
req.ip
|
||||
end
|
||||
|
|
@ -218,9 +218,9 @@ You can subscribe to 'rack.attack' events and log it, graph it, etc:
|
|||
|
||||
## Testing
|
||||
|
||||
A note on developing and testing apps using Rack::Attack - if you are using throttling in particular, you will
|
||||
need to enable the cache in your development environment. See [Caching with Rails](http://guides.rubyonrails.org/caching_with_rails.html)
|
||||
for more on how to do this.
|
||||
A note on developing and testing apps using Rack::Attack - if you are using throttling in particular, you will
|
||||
need to enable the cache in your development environment. See [Caching with Rails](http://guides.rubyonrails.org/caching_with_rails.html)
|
||||
for more on how to do this.
|
||||
|
||||
## Performance
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
module Rack
|
||||
module Attack
|
||||
VERSION = '2.2.1'
|
||||
VERSION = '2.3.0'
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ describe 'Rack::Attack.throttle with limit as proc' do
|
|||
before do
|
||||
@period = 60 # Use a long period; failures due to cache key rotation less likely
|
||||
Rack::Attack.cache.store = ActiveSupport::Cache::MemoryStore.new
|
||||
Rack::Attack.throttle('ip/sec', :limit => lambda {|env| 1}, :period => @period) { |req| req.ip }
|
||||
Rack::Attack.throttle('ip/sec', :limit => lambda {|req| 1}, :period => @period) { |req| req.ip }
|
||||
end
|
||||
|
||||
allow_ok_requests
|
||||
|
|
|
|||
Loading…
Reference in a new issue