* docs: Improve Getting Started section
* docs: Following Getting Started show Usage to the README reader
* docs: Move the configuration tip to the Usage section
* docs: Move the cache store configuration comment to Usage
* docs: Clarify Responses title
* docs: allow2ban also uses the cache store
* docs: Improve Usage docs for blocking, safelisting and throttling
* docs: Don't give the impression that the gem is not being maintained when it actually is
* docs: Be a bit more clear about cache store in README
* docs: Attempt to be a bit more concise in the README intro
* docs: Clarify sentence
- Notes that the rails cache is also used for fail2ban
- Notes that all fail2ban filters use the same cache for counting and banning
- Expands sample fail2ban filter example to include more matches
I have a response which is a class. While I can still have my class
implement `#[]`, it does look a bit off. On the other side, having
objects, responding to #call, that are not procs is pretty common.
So I propose to invoke the responses with `#call` to let users override
it with response objects, that respond to `#call` instead of `#[]`.
I need to filter requests on a period I need to get dynamically out of
information I have in the requests. Currently, I can work out the limit,
as it can be a `Proc`, however I can't do that with the period.
This PR adds support for that. Tried to do it in a way that doesn't
brake backwards compatibility, as periods are coerced to numbers during
`Rack::Throttle` initialization.
Using three tick marks and double indenting is redundant. Doing both produces a readme with an odd visual flow. This change does not modify content, it only changes lefthand whitespace so the Readme on Github will be more coherent.
An alternate to fail2ban that allows clients until they hit the
thresholds, then blocks them. Think of it like a throttle where you can
block for more than one period.
