rate-limit initial implementation

[podviaznikov]

Added/Changed:

1. rate-limits for secure API endpoints
2. added redis dependency. Updated project to work on Heroku but didn't tested it there.
3. rate limits can be customized though the config file

Open questions:

1. Maybe we shouldn't have rate-limits for admins?
2. Login endpoints are not rate-limited. Should discuss strategy in more details

Todo:

1. Cover rate-limits with tests

[hulbert]

Couldn't this cause issues since the web interface uses the API? Isn't this just rate limiting logged in users' requests? Perhaps I am misunderstanding the goal

[podviaznikov]

@hulbert I had the same question as you. That is why I had first open question. I thought that we should at least disable rate-limits for admins because it will prevent from UI use.

[davidkaneda]

@podviaznikov @hulbert Hey guys, great stuff. Here are some thoughts on the questions:

• I wouldn’t worry too much about the admin app usage... This work is actually more for when we allow admins to generate API tokens (or use OAuth), but essentially: Once we start gating "external" API requests (currently we just use session-based, which won't be enough for app devs). For now, perhaps just bump apiHourlyLimit to ~10,000?
• The Redis2go choice is great, and thanks for adding into Travis as well :)
• What are your thoughts/questions on the login aspect? Does it not make sense to use the rate-limiter here (and easier to save a lock on the User model?). Totally up to you... would love to see an implementation here, though :)

All make sense? Just let me know if you have extra questions/ideas!