I understand the reasoning for "use the cache", but not every site has caching enabled, especially lots of smaller sites. A separate table could be used for tracking attempts, and cleared out per user on successful login attempt/ip address. This table would not need to be huge if designed with performance in mind. Caching could be layered on (check cache for bans but not for maintaining counts) or we could have a cache backend in addition to a database backend. I'm aware that django has a database cache backend, but any database solution in this space should be designed with the database in mind and not just essentially blob storage.
For what it's worth, I've used django-axes (https://pypi.python.org/pypi/django-axes) with some success in the past and will probably use it again for my current project. I don't think the username based protection is adequate though: AXES_LOCK_OUT_BY_COMBINATION_USER_AND_IP: If True prevents to login from IP > under particular user if attempts limit exceed, otherwise lock out based on > IP. > Distributed attack on a particular user would not be caught in this configuration. Cheers -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/dcb1395e-c93a-410e-839d-3c06f39d8d40%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
