You might consider using a simple servlet filter for this. Capture
the remote IP address from the request, put the address on a list with
a timestamp, then retrieve the list item on the next request. If the
two timestamps are not sufficiently separated in time, then return 400
Bad request or some such.
You might use ehcache to cache the request IP address and timestamp
blob. ehcache will do the aging-out for you, per the cache config.
On Thu, Mar 3, 2011 at 2:55 AM, Tauren Mills <tauren_at_groovee.com> wrote:
> I have two related questions.
> First, are there any Jersey features for throttling connections from users?
> Services such as Twitter only allow a certain number or requests per time
> period. How would I do something similar? Is this something that is better
> handled by a proxy or other service?
> The thing is, I'd like to have varying service levels based upon the "plan"
> the user is paying for. So whatever is doing the throttling would need to be
> able to access business logic.
> Secondly, I have a specific use case that needs even more strict API abuse
> prevention measures. I'm sure doing this probably isn't a best practice, but
> my API allows new user accounts to be created. The web UI is a single-page
> javascript app, and there are mobile, iphone and android apps, all which
> need to be able to create accounts. Third-party apps will be able to provide
> UI for users to create accounts as well. So using a RESTful API call is
> quite convenient.
> But are there any good ways to keep bots from automatically signing up lots
> of accounts? Perhaps any given IP can only sign up one account per minute.
> But what about all those AOL users, or corporate users behind firewalls?
> As a pure API solution, there would not be a CAPTCHA involved. But perhaps
> there could be. What if the client was required to make an initial request
> to gain permission to create an account? That permission request would
> respond with something like:
> http://somewhere.com/api1/account/permission
> {
> request_id: 2ab3f98ce
> captcha_image: http://somewhere.com/captchas/2ab3f98ce.gif
> }
> Then the API call to create an account would include the request_id plus the
> "answer" to the captcha image. It could also require at least 10 seconds
> before the /account/permission call and the /account/create call to make
> sure a human is doing the work, not a bot.
> But I hate CAPTCHAs, especially in my mobile apps. And it seems like there
> should be a better solution. Any ideas?
> Tauren
>
>
>
>
--
Mark
