Modify

Opened 17 years ago

Last modified 13 months ago

#843 new enhancement

Make admin approval required for account registration

Reported by: anonymous Owned by:
Priority: normal Component: AccountManagerPlugin
Severity: normal Keywords: user register prevention admin
Cc: Thijs Triemstra, sukender@…, Tim Niemueller 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 (25)

comment:1 Changed 17 years ago by rupert thurner

see #442 for email validation.

comment:2 Changed 17 years ago by rupert thurner

see #1427 for mandatory password change on first login.

comment:3 in reply to:  description ; Changed 15 years ago by Thijs Triemstra

Cc: Thijs Triemstra 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 14 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 13 years ago by Steffen Hoffmann

Keywords: user register prevention admin added
Owner: changed from Matt Good to Steffen Hoffmann
Summary: make account registration more secure/uniformMake 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.

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 13 years ago by anonymous

Cc: sukender@… added

comment:7 Changed 12 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 12 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 Changed 12 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 12 years ago by Steffen Hoffmann

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 12 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 12 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 12 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 12 years ago by Steffen Hoffmann

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

comment:15 Changed 12 years ago by anonymous

Cc: Tim Niemueller added

comment:16 Changed 12 years ago by Steffen Hoffmann

(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 12 years ago by Steffen Hoffmann

Trac Release: 0.100.11

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

comment:18 Changed 12 years ago by Steffen Hoffmann

(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 11 years ago by Steffen Hoffmann

(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 11 years ago by Steffen Hoffmann

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 11 years ago by Steffen Hoffmann

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

comment:22 Changed 11 years ago by Steffen Hoffmann

(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 11 years ago by Steffen Hoffmann

(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 11 years ago by Steffen Hoffmann

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

comment:25 Changed 7 years ago by Ryan J Ollos

Owner: Steffen Hoffmann deleted

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.

Add Comment


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

 
Note: See TracTickets for help on using tickets.