Open Cryptophobia opened 6 years ago
From @bacongobbler on March 21, 2016 19:14
Would some kind of rate-limiting feature fix this?
From @jchauncey on March 21, 2016 19:21
I think it depends on how complicated we want to get. Honestly, this probably plays into a larger theme feature which is Org management/security enhancements/(auth/id) management. But I think after 3 or 5 times you are locked out until an admin unlocks you or we trigger an unlock event somehow.
From @helgi on June 10, 2016 21:54
https://www.djangopackages.com/grids/g/antiflood/ here are a few - tho most will want a cache (redis / memcache) of some sort to store login attempts, etc
From @Joshua-Anderson on September 8, 2016 18:6
We have a redis component now so the cache is no longer a blocker.
From @helgi on September 8, 2016 18:9
That redis component is used for logging - we shouldn't be re-using components all too much. We could do it but then we'd have to do more sanity checking / users / acl kind of dealio so logger doesn't blow up controller cache and other way around
From @Joshua-Anderson on September 8, 2016 18:12
True, I was thinking we would use a second database on the redis component or we would deploy the deis-redis component twice, once for logger and once for the controller.
From @bacongobbler on September 8, 2016 18:26
Redis has a default of 32 "databases". IIRC logger is only using one, so there's nothing technically stopping us from using another :)
From @jchauncey on March 21, 2016 18:48
Right now we do not restrict the number of times people can fail a login attempt.
Copied from original issue: deis/controller#544