Make admin approval required for account registration

[anonymous]

While the account manangement itself is quite nice, it looks like just everyone can register some account without it beeing checked at all. What I would suggest is a (configurable) combination of those mechanisms:

• captcha authentication to prevent robots from creating accounts
• email verification links to the email entered
• admin approval of accounts

Also passwords should be stored within the database, so that it could be made easier for existing projects to incorporate trac into their user schemes.

[ThurnerRupert]

see #442 for email validation.

[ThurnerRupert]

see #1427 for mandatory password change on first login.

[thijs]

Replying to anonymous:

• admin approval of accounts

Was there a ticket opened for this feature?

[anonymous]

Replying to thijs:

Replying to anonymous:

• admin approval of accounts

Was there a ticket opened for this feature?

See the ticket #5992

[hasienda]

Replying to anonymous:

While the account manangement itself is quite nice, it looks like just everyone can register some account without it beeing checked at all.

I do totally agree, that AccountManagerPlugin would profit from some mechanisms to fight bot registration and other ways to prevent undesired account and content creation or changes.

What I would suggest is ![...]

Very well, but I'll adhere to a more fine-granular approach on issue tracking.

• captcha authentication to prevent robots from creating accounts

We've got #2707 and #2897 for captcha support on registration, both with patches and positive feedback from at least one other user.

• email verification links to the email entered

This feature has been implemented meanwhile at least for the user with changeset [3799]. Admin interface integration is pending (see #442 and #7111).

• admin approval of accounts

AFAIK, this remains as the only unique suggestion here. Therefor I'll change title to continue with tracking just this one.

Also passwords should be stored within the database, so that it could be made easier for existing projects to incorporate trac into their user schemes.

IMHO db store (SessionStore) without interface to AccountManagerPlugin or even Trac itself is equal to effectively hiding that data from other application. So the first part of that quoted sentence contradicts the second part, right?
Alternatively/better

• provide shared access to user credentials to both, Trac and your other application, as already done with HtPasswordStore, or
• implement support for centralized login/single-sign-on, i.e. with OpenIDAuth (#173) or RadiusAuth (#6788) support.

[bfloch]

Wouldn't a quick option be to send the verification email to the admin rather than the user?

[bfloch]

I have to correct. Since you need to be logged in to verificate this doesn't work.
So the alternative would be to provide a method / link to verify for the admin and send a alternative email to the user while the email for the admin could point to the profile page once the verification button is added there.

[bfloch]

Rethinking:
Possibly verification is the wrong area / term since we are not verifying anything.
Users should be created, regardless of the verification status as locked!
This would be the mechanishm we look for. Without any big effort.

[hasienda]

Replying to bfloch:

Rethinking:
Possibly verification is the wrong area / term since we are not verifying anything.

Yes, I had quite similar feelings about this tickets topic.

Users should be created, regardless of the verification status as locked!
This would be the mechanishm we look for. Without any big effort.

So you suggest to use account locking to create new users as locked-by-default? This should be configurable, maybe even visibly declared at the registration page, if enabled, but it's a nice idea indeed.

Any idea on the option name? Because this could be a crucial part for good application setup support, and I tend to fail in providing most-intuitive wording certainly due to not being a native English speaker.

[bfloch]

I actually have a (hacky?) implementation going on. I named the option "user_lock_on_creation"
One drawback though is that there is no real "lock" attribute but rather the lock is calculated each time from the lock settings (login_attempt_max_count etc.).

So this solution won't work if you don't have locking enabled at all.
In my case I have set the login_attempt_max_count to something like 12 and the user_lock_max_time to 0 (infinity) which is an ideal setting for the hack.
Now at the end of _create_user (web_ui.py) I check for login user_lock_on_creation and set failed_logins_count to the current attemtpt_max_count.

That's all folks. I'd share some code but because of the problem above this can't be used as official solution.

[bfloch]

A better approach would be to introduce an additional user attribute called forced_lock or similar and change the lock code to be locked if set and the unlocking code to delete the attribute.

This way it would work independent of the general locking.

[bfloch]

I just want to add that using the locking mechanism for this feature works really well because all other options like verification are unaffected and work like expected once unlocked and the unlocking by admin is already implemented.

So it might be worth it. I could see if I can come up with a better implementation for the trunk and submit a patch.

[hasienda]

I've many more issues to take care for, so your effort is highly appreciated. Thank you.

[hasienda]

(In [11961]) AccountManagerPlugin: Admins add verified accounts by default, refs #843 and #10142.

If email verification is enabled, accounts created via the account property
editor in AccountManagerAdminPanel are verified by default. Note, that
the new user could still get an initial password assigned using the
<Reset password> button on the same page.

A couple of small template improvements have been added, that I held off until
now, because they'll need translators attention too. This is a good occasion.

[hasienda]

Hm, requested for a long time, still this will not be back-ported without urgent request.

[hasienda]

(In [11983]) AccountManagerPlugin: Some changes made with an eye on pylint check results, refs #843 and #10142.

Well, guess that especially [11961] has been a bit premature, and glad that
I checked it that soon.

[hasienda]

(In [12398]) AccountManagerPlugin: Releasing version 0.4, pushing development to acct_mgr-0.5dev.

Availability of that code as stable release
closes #874, #3459, #4677, #5295, #5691, #6616, #7577, #8076, #8685, #8770, #8791, #8990, #9052, #9079, #9090, #9139, #9246, #9252, #9547, #9618, #9676, #9843, #9852, #9940, #10023, #10028, #10123, #10142, #10204, #10276, #10397, #10412, #10594, #10625 and #10644.

Some more issues have been worked-on, yet without confirmed resolution,
refs #5464 (for JiraToTracIntegration), #8927 and #10134.

And finally there are some issues and enhancement requests showing progress,
but known to require more work to resolve them satisfactorily,
refs #843, #1600, #5964, #8217, #8933.

Thanks to all contributors and followers, that enabled and encouraged a good
portion of this development work.

[hasienda]

Glad to announce a preliminary implementation for registration approval, some working unit tests and positive test results from my development system.

I expect to commit the initial change-set for this feature soon. From there it'll be extended towards supporting permanent administrative account locking (#8595) - independent of conditional locking on failed login attempts.

[hasienda]

(In [12502]) AccountManagerPlugin: Implement a new account approval feature, refs #843.

[hasienda]

(In [12503]) AnnouncerPlugin: Extend AccountManager notifications as required, refs #843, #7759 and #7977.

Note, that any previous version of TracAnnouncer won't work with latest
AccountManagerPlugin 'trunk' code, and this already made me thinking about
a more robust change listener definition. But this is another subject.

[hasienda]

(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.

[hasienda]

(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.