Feature Proposal: Create mechanism for easy user deletion without file access

Motivation

A routine task for administering a foswiki site is deleting users, most commonly because of spam registrations but also due to errors during user registration or creating test users. Currently, in the case of the most common user authentication setup, this involves three steps: deleting the user topic, removing the user from WikiUsers topic, and deleting the entry in the password file. Often times the person responsible for moderating the site on day-to-day basis doesn't have file-level access necessary to edit the password file. It would be nice if there was a ui accessible only to AdminGroup (or other designated group) that would execute these actions in one step.

Description and Documentation

Create a form accessible only to AdminGroup that allows the selection of one or more users which are then deleted in one step.

Obviously, this mechanism would require taking into account the particular authentication setup for the site.

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: LynnwoodBrown - 15 Jun 2012

Discussion

This is already implemented in the AntiWikiSpamPlugin. When passed a WikiName

• It de-registers the user using the Mapper removeUser fuction
  • This depends on recent Mapper updates to clean the WikiUsers topic.
• It moves the User topic to Trash with a SuspectSpammer prefix
• It removes the user from any Group membership.

I think you can flip this to "Implemented as an Extension".

Oh.. and in 1.1.5, the Registration process is hopefully much better about cleaning up after registration failures. It should not be leaving behind partially registered users any more.

-- GeorgeClark - 15 Jun 2012

Moving the user topic to trash makes sense cleaning up spam registrations. However, when an employee leaves the company, you'd like to (a) keep his/her user profile topic for further reference. Or (b) you'd like to replace it with a placeholder template noting when JohnDoe left the organization and how to contact him from now on.

This is even more important to block any further user registrations to reuse JohnDoe as a WikiName as this would potentially give him access rights only granted to the one that used the JohnDoe WikiName before. Likewise, all edits of the former JohnDoe would be associated with the new JohnDoe, even though he is not responsible for the mess left behind. In that case all John Does must get unique login and WikiName IDs from the very start of the wiki. Keeping a (placeholder) user profile might mitigate this issue.

-- MichaelDaum - 29 Oct 2012

There is already a deleteUser function within Foswiki::Manage and Foswiki::Register, but I'm not familiar with how they might be used. In looking at the code, it appears that it is intended to "self-remove" users? (It wants the user to supply their own password). It removes the user from the mapper, but doesn't touch the users topic. Does anyone know if this function is actually used, and if an improved function has to implement the old mechanism? It is not documented in ManagingUsers, and is listed in the CommandAndCGIScripts#A_61action_61deleteUserAccount_61 as Unregisters (removes) the currently logged-in user.

Could your concerns be handled if I added a checkbox to Delete User Topic. If checked (default), topic is moved to Trash, otherwise the user's topic is left in the Users web.

-- GeorgeClark - 29 Oct 2012

It would really be cool to have four choices:

1. delete user and his profile page: this effectively removes him from the mapper too
2. same as (1) but block the same user ID from being registered again (e.g. by adding an ! into the passwd column of htpasswd)
3. delete user but not his profile page: the user remains as part of the mapper blocking any later user registration from taking over an old user ID
4. same as (3) but an alumni template is copied over the user profile page with admin change access

That's what I tried to outline above. The normal use case for (1) and (2) is spam registrations. The use cases for (4) and (5) are deletion of a regular user. It is quite important to take precautions to protect against an accidental reuse of an old user ID. Audit trails depend on an identity to remain intact and not being taken over as part of a user deletion by accident.

-- MichaelDaum - 29 Oct 2012

I'd like to keep the scope of this to just the Manage and Register scripts.

1. Delete user and profile.
2. Out of scope Block the user needs changes to PasswordManager, and API changes to support a "disabled" user. I don't believe there is consensus on how to disable a user in .htpasswd. Foswiki::Users and Foswiki::Users::HtPasswdUser do not have a disable function. And other password managers would need a similar function.
3. Delete user, but not profile page - simple enough to handle in this scope.
4. Copy over the template... I can probably do this as well, but I need some guidance. Would this:
   • completely replace the user topic (Move to trash and create new template topic),
   • Check in a new revision, containing only the alumni information, or
   • merge the template information into the user's topic.
   • I assume that the user form needs to be removed, so that utilities won't find it as a user (like the tool to rebuild WikiUsers).

-- GeorgeClark - 30 Oct 2012

Checked in the initial work early. Option 1 and 3 handled, but need work. No progress on option 4.

-- GeorgeClark - 31 Oct 2012

Hm good points. I thought "disabling" a user was easy enuf in the .htpasswd case: new password is !, which never matches any real one.

-- MichaelDaum - 31 Oct 2012

I think we need to have a separate proposal to decide how to disable users.

• TWiki "comments" entries in .htpasswd and has extended the Users API with getUserData() and setUserData() methods. That complicates things as the user is then hidden from the mapper.
• You mention set password to !, but the email address also needs to be deleted, or the user can still request a reset.

For modifying the user topic, I suspect this will probably vary by installation practice. Maybe the best solution would be to add a plugin handler call early in the delete process

 =deleteUserHandler( \$userTopicObject,  \%data )  -> boolean  
   - $data->{cUID}
   - $data->{wikiname}
   - $data->{loginname}
   - $data->{emails}
   - $data->{notify} Flag, should notification be sent to the list of emails.
   - $data->{renameTopic} Set to false to stop topic rename
   - $data->{newName} The Web.Topic name used for the rename

If hander returns false, the user will not be removed. $userTopicObject can be modified and saved by the exit.

-- GeorgeClark - 31 Oct 2012

After further discussions with MichaelDaum on IRC about should this be part of the mapper or a handler, and should Register even be creating the user topics, or should it be left to the mapper. The scope on this should probably be limited to implement no more than what AntiWikiSpamPlugin does today. If we add handlers, then we would need to deprecate them if it's not the right solution. We need separate FeatureProposals for

• Move user topic management to the Mapper
  • How to deal with archiving user accounts
• How to disable users and manage disabled accounts
  • Implement TWiki methods, or use some other approach

The deleteUserAccount feature already exists, in a very limited implementation. This proposal is not making any API changes, only increasing its existing functionality.

-- GeorgeClark - 31 Oct 2012

One more issue was discovered. When a user is deleted while they are still logged in, the session is still usable. For this to be complete, any current sessions need to be removed.

See Item.12699 for a task to add LoginManager::removeUserSession()

-- GeorgeClark - 20 Dec 2013

Commenting is disabled while not logged in