Ability to ban accounts

Well second first: Not that I would reject a dedicated ban functionality, but with (administratively) adding a dummy user you could effectively disable this for new accounts, if you enable registration support in a recent AcctMgr version. I've been testing this a lot, so this should work. If not, tell me your issues.

I've already thought about that recently. It would be achievable without adding more logic by setting an account lock somewhere far in the future. But OTOH it'll lock little too hackisch to be nice, and imaging a login failure along the lines of "...try again in 50 years..." that would certainly surface in that setup. So this is not the best solution.

What we should do is adding dedicated administrative account locking, right?

As a side-note I think there is not much difference from deleting the account(s) AFAIK. It would be much more useful, if we were able to do kind of a fake-login for such accounts and just deny any action. This should be much more effective against automated approaches, because it'll waste more of their resources (admittedly at the Trac side too). I wonder if this could still be intergrated via an own permission provider inside AcctMgr. Do you agree or it there something totally missing/wrong at my side?

Replying to hasienda:

Well second first: Not that I would reject a dedicated ban functionality, but with (administratively) adding a dummy user you could effectively disable this for new accounts

Right. What I've been doing is changing the password on any accounts I want to ban. However, I think your approach is better, as if the user stays logged in, they'll still be authenticated once the password is changed. Another problem with my approach is that I can't tell which accounts are banned accounts. I guess with your approach, I could set the account name to indicate this.

I've already thought about that recently. It would be achievable without adding more logic by setting an account lock somewhere far in the future. But OTOH it'll lock little too hackisch to be nice

Agreed.

What we should do is adding dedicated administrative account locking, right?

Agreed.

As a side-note I think there is not much difference from deleting the account(s) AFAIK. It would be much more useful, if we were able to do kind of a fake-login for such accounts and just deny any action.

If I understand what you're suggesting, treating the accounts in the same way unverified accounts are treated would work nicely.

Replying to jteh:

Replying to hasienda:

Well second first: Not that I would reject a dedicated ban functionality, but with (administratively) adding a dummy user you could effectively disable this for new accounts

Right. What I've been doing is changing the password on any accounts I want to ban. However, I think your approach is better, as if the user stays logged in, they'll still be authenticated once the password is changed. Another problem with my approach is that I can't tell which accounts are banned accounts. I guess with your approach, I could set the account name to indicate this.

The first consideration was just regarding blocking emails. Sorry, if I wasn't clear enough. So it wont' help for your "already logged in" scenario. Only my last suggestion would do, since we could revoke an authentication via that custom !IPermissionPolicy more or less silently at any time.

[...]

As a side-note I think there is not much difference from deleting the account(s) AFAIK. It would be much more useful, if we were able to do kind of a fake-login for such accounts and just deny any action.

If I understand what you're suggesting, treating the accounts in the same way unverified accounts are treated would work nicely.

Exactly. And the longer I think about it, the more I like the idea.

Release of acct_mgr-0.4 helped to cut down a rather long list of issues.

Hereby I acknowledge, that - while working at #843 - now this feature is finally getting serious attention.

I've got a preliminary implementation for registration approval, some working unit tests and positive test results from my development system. So this is definitely on its way now.

(In [12504]) AccountManagerPlugin: Use new account approval feature to ban accounts, refs #843 and #8595.

While simple, this might be an effective counter-measure against spammer registrations, because intentionally it's rather hard to spot the difference between an approved authenticated session and one with pending approval. So I forsee more wasted resources on attacker's side to figure out, why one still fails to spam the site even after successful registration, and that is certainly a good thing.

Note: Due to its implementation banning is instantly effective and will prevent even authenticated sessions from doing more than a user could in an anonymous session, unlike the account lock provided by AccountGuard. That wouldn't prevent authenticated sessions from continuing indefinitely, at least until next authentication time, and this might be a rather long time, if persistant sessions had been allowed before.

(In [12505]) AccountManagerPlugin: Some enhancements regarding approval/ban feature, refs #843, #8595 and #10741.

Adding the registration approval configuration option to config admin panel. Taking care for marking all potential message parts for translation as well. A recent suggestion by Ryan J Ollos is merged in here too, so that all kinds of restricted accounts are clearly visible in user listings now.

The current tests in the user admin template are not totally sufficient yet.

I.e. they won't detect 'ACCTMGR_USER_ADMIN' privileges for any account and wrongly mark them with 'Approval revoked', while this is impossible. These accounts are excluded intentionally from permission cut-down. I'll take care for this detail when establishing a better test abstraction for all kinds of account limiting.

#10002 has been closed as a duplicate of this ticket.

Replying to rjollos:

Yes, I agree it is a duplicate now that the Toggle account approval feature is in place. The only reservation I had was that it might not be completely obvious to someone that Toggle account approval is the way to lock an account, but I think we can cover that in the docs.

I coined 'Toggle' for shortness to describe the universal function that this button really has: Once press will approve accounts with state 'pending' set on registration time (once) and switch on/off account banning for the rest of selected accounts.

How about adding a more descriptive and verbose tool-tip then? Suggestion: "Approve pending registrations, ban/unban accounts"

Replying to hasienda:

How about adding a more descriptive and verbose tool-tip then? Suggestion: "Approve pending registrations, ban/unban accounts"

Yeah, I think that would be a useful addition.

(In [12571]) AccountManagerPlugin: Add descriptive tool-tip to 'Toggle account approval', refs #7426 and #8595.

A CSS style comment is now corrected as well.

Thanks to Ryan J Ollos for hints on these minor issues, nevertheless I care and I'm happy to receive code reviews for getting things straight.