Modify

Opened 8 years ago

Last modified 9 months ago

#843 new enhancement

Make admin approval required for account registration

Reported by: anonymous Owned by: hasienda
Priority: normal Component: AccountManagerPlugin
Severity: normal Keywords: user register prevention admin
Cc: thijs, sukender@…, TimN Trac Release: 0.11

Description

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.

Attachments (0)

Change History (24)

comment:1 Changed 7 years ago by ThurnerRupert

see #442 for email validation.

comment:2 Changed 7 years ago by ThurnerRupert

see #1427 for mandatory password change on first login.

comment:3 in reply to: ↑ description ; follow-up: Changed 6 years ago by thijs

  • Cc thijs added; anonymous removed

Replying to anonymous:

  • admin approval of accounts

Was there a ticket opened for this feature?

comment:4 in reply to: ↑ 3 Changed 4 years ago by anonymous

Replying to thijs:

Replying to anonymous:

  • admin approval of accounts

Was there a ticket opened for this feature?

See the ticket #5992

comment:5 in reply to: ↑ description Changed 4 years ago by hasienda

  • Keywords user register prevention admin added
  • Owner changed from mgood to hasienda
  • Summary changed from make account registration more secure/uniform to Make admin approval required for account registration

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.

comment:6 Changed 4 years ago by anonymous

  • Cc sukender@… added

comment:7 Changed 3 years ago by bfloch

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

comment:8 Changed 3 years ago by 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.

comment:9 follow-up: Changed 3 years ago by 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.

comment:10 in reply to: ↑ 9 Changed 3 years ago by 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.

comment:11 Changed 3 years ago by 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.

comment:12 Changed 3 years ago by 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.

comment:13 Changed 3 years ago by 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.

comment:14 Changed 3 years ago by hasienda

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

comment:15 Changed 3 years ago by anonymous

  • Cc TimN added

comment:16 Changed 2 years ago by 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.

comment:17 Changed 2 years ago by hasienda

  • Trac Release changed from 0.10 to 0.11

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

comment:18 Changed 2 years ago by 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.

comment:19 Changed 2 years ago by 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.

comment:20 Changed 2 years ago by 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.

comment:21 Changed 2 years ago by hasienda

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

comment:22 Changed 2 years ago by 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.

comment:23 Changed 2 years ago by 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.

comment:24 Changed 2 years ago by 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.

Add Comment

Modify Ticket

Action
as new The owner will remain hasienda.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.