Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #435 (closed enhancement: wontfix)

Opened 13 years ago

Last modified 10 years ago

Identity should monitor login attempts and prevent locked users from logging in

Reported by: ksenia Owned by: anonymous
Priority: normal Milestone: 1.x
Component: Identity Version:
Severity: normal Keywords: login locked user
Cc:

Description

I think it would be very handy if identity will monitor login attempts and after several (config file option?) failed logins from the same visitor (the same IP / user agent / ??? ) call user-defined function. Another request: extra column "locked" in TG_User, and prevent locked users from logging in.

Change History

comment:1 Changed 13 years ago by Jeff Watkins

  • Milestone 1.0 deleted

This is definitely a post 1.0 feature.

comment:2 Changed 13 years ago by godoy

I would like this, but does it belong to core identity? Shouldn't this be an extension? It would implicate in logging successful and failed logins (or resetting the status for the user after each successful login...).

Also, I believe that this can be solved with #313... What do you think?

comment:3 Changed 13 years ago by jorge.vargas

  • Milestone set to 1.1

comment:4 Changed 12 years ago by alberto

  • Milestone changed from 1.1 to __unclassified__

Batch moved into unclassified from 1.1 to properly track progress on the later

comment:5 follow-up: ↓ 6 Changed 10 years ago by jorge.vargas

  • Milestone changed from __unclassified__ to 1.x

for tg2 this should be a repoze.who plugin, which should be reported in this trac.

for tg1 it is still a valid feature request

comment:6 in reply to: ↑ 5 Changed 10 years ago by Gustavo

Replying to jorge.vargas:

for tg2 this should be a repoze.who plugin, which should be reported in this trac.

I'd say it'd be so application-specific that it wouldn't worth trying to deal with that in the form of a generic attempt, either in a new repoze.who plugin or inside TG2 itself. First of all, the meaning of "banned user" may differ greatly from one application to another, as well as the way to identify them. Therefore if it was a feature request for TG2 I'd most probably mark it as wontfix.

For example, in a rather simple situation (too simple to be true) where there's a "banned" attribute in the User model to tell if the user has been banned and if you were using the repoze.who SQLAlchemy authenticator plugin, you would subclass it as:

from repoze.who.plugins.sa import SQLAlchemyAuthenticatorPlugin

class MyBanningAwareAuthenticator(SQLAlchemyAuthenticatorPlugin):
    def authenticate(self, environ, identity):
        userid = super(MyBanningAwareAuthenticator, self).authenticate(environ, identity)
        user = identity.get('user')
        if user and not user.banned:
            return userid

That'd be all the code you'd need to prevent banned users from logging in in TG2 with repoze.who. But wait, what if the user got banned because of many failed login attempts (from somebody else) and now *she* (the real user) does want to log in? Well, this is your way of handling that situation, so it's up to you to handle the other aspects involved. And of course, it'd be specific to your application (what are the actions that ban users? how can they get unbanned? that's all app-specific).

for tg1 it is still a valid feature request

In my opinion, it should be implemented on a per application basis, even in TG1.

comment:7 Changed 10 years ago by jorge.vargas

  • Status changed from new to closed
  • Resolution set to wontfix

I agree with Gustavo. We have too many corner cases, maybe this could be a feature of tgext.profile.

Note: See TracTickets for help on using tickets.