Proposed - DeleteUserAccount

A number of User Removal tools are needed

1. a TWikiUser to remove their Account (and archive their UserTopic and its links)
2. a TWikiAdmin to remove a User's Account (and archive their UserTopic and its links)
3. a TWikiAdmin to suspend a User's Account (possibly as a final step in registration?)

this is not intended to

1. be a tool for people to re-register by removing their account (this should be done using ResetPasswdByEmail)

If a user is finished with their TWikiPresense they might want to clean up and remove their name from all contributions. (I know there are a few wiki's i thought about doing this). This can be acheived by Moving their UserTopic from SvenDowideit to Main.Contributor1234 (and all the links), and then removing their password entry.

This would allow a new person of that name to register, and would prevent the (unintentional) hyjacking of their contributions.

for now i am going to ignore the rcs entries - we may or may not want to allow removing their name totally.

Progress

Done

• separated out the Password code from (RegisterCgiScript, InstallPasswdCgiScript, PasswdCgiScript) into UserDotPm
• moved the htpasswd specific code into HtPasswdUserDotPm
• move htpasswd CGI code from PasswdCgiScript into InstallPasswdCgiScript
• move generic PasswdCgiScript code into ManageCgiScript
• add delete user code into ManageCgiScript, and UserDotPm (and implement in HtPasswdUserDotPm)
• fix ResetPassword
• fix ChangePassword
• fix InstallPassword
• create DeleteUserAccount
• Add PavelGoran's ConfigurablePasswordFileHandling changes
• add a NoPasswdUserDotPm
• we should stop registrations to the AnonymousContributorXXXXX Topics

ToDo

• check if the user is in a group (esp the AdminGroup) and refuse to delete the account (or automate the removal?)
• Delete user code does not yet rename the user topic (and it's links) as I need a ServerUniqueId for the AnonymousContributor TopicName
• Remove the FredQuimby line from the TWikiUsers topic
• Remove user from all groups and from all the ALLOWWEB/ALLOWTOPIC... declarations, if any.
  • Note: Otherwise this is a security hole as the first one to re-register with this name will be granted the permissions of the previous user.
• remove forms from TWikiUserAuthentication
• make an Admin Use interface - DeleteUserAccount removed the user that is authenticating, not some other Account..
• EmailResetPassword
• Add a tickbox to allow the removal of the user's topic (with rename to AnonymousContributorXXXX)
  • if not, lock the topic to Admin ?? ( mor eimportant for public webs..? )
  • When DeleteAccount renames the userTopic it should probably also do topics that user does not have access rights to.. eeeek
• update Documentation
  • MaintenanceGuide

Optional

• autodetect presence of HtPasswd, and otherwise use a default implementation of User.Pm

A user just complained that he could not delete his account. If we want to be LeadingEdge we need to provide this.

-- MartinCleaver - 27 Nov 2003

That would be a useful enhancement, especially for high volume public sites!

-- PeterThoeny - 01 Dec 2003

I'm going to refuse to delete a user in the AdminGroup (or if I can, any group) so that a subsequent user can't join a group by registering that name ..

I want to do this work while doing HtPasswordCodeDuplication, as I want to do a RegisterUser in the 'pre-http' twiki install so that we can garantee that there is a valid AdminGroupUser.

This makes me think that we could do with a user management topic that allows the user to see what goups they belong to, and change them (like subscriptions), this would allow changing passwords, deleting etc..

-- SvenDowideit - 02 Dec 2003

As Sven points out, this needs some further thoughts; there are different requirements for public sites and firewalled sites.

At my workplace we keep all user pages, but do this for employees who left the company:

• replace the content of the user topic with a "left company on ..." bullet; sometimes with a link to a contact person for follow-up
• in TWikiUsers, move the user's bullet down to a "no longer with the company" section

This solves these issues:

• Signatures of contributors still work
• Revision control works, e.g. the login name of the user still gets mapped to the WikiName
• Documented who takes over the responsibilities
• The search form to search for employees ignores those "left company on ..." topics

These points need to be addressed for a delete user feature:

• configurable behaviour for public sites and firewalled sites
• possibly a switch to deny / allow for admin / allow for user to remove a user registration
• the user needs to be removed from all groups, else someone could impersonate that person and gain access to restricted content

A TWiki/User.pm module consolidating the user management code, invoked by the ManageCgiScript (while retiring the password scripts) is a sensible approach. For performance on non mod_perl installations, the User module should be loaded only when needed.

-- PeterThoeny - 02 Dec 2003

for now i am going to move the current ResetPassword function into the InstallPasswdCgiScript so that they are a matching pair dependant on TWiki::User::HtPasswdUser and the PasswdCgiScript and RegisterCgiScript will be more generic, and so dependant on TWiki::User.

Reset should become to be 3 phase.

1. email out to the TWikiUser's email address, with a generated password, and an uniqueID (both saved somewhere for that user??
2. the user enters the ID, which then tells the script to change the password
3. takes them to the ChangePassword topic.

this is still vunerable to someone changing the email address on a user's topic - any ideas??

Re: EmailResetPassword, ForgettingPasswords, eeeeeek UserAuthorizationSchemes

Also: why do we have LoginName on RegistrationPub but then not use it for logging in ? (can we remove it ?).

-- SvenDowideit - 06 Dec 2003

is there a oops template for an unsupported request to a script?

-- SvenDowideit - 15 Dec 2003

Please keep in mind that some, like me, may wish to have empty (e.g. no) passwords. For example I like the way Meatball (usemod) works in this regard. http://www.usemod.com/cgi-bin/mb.pl?action=editprefs

What I want is to be able to say is "my name is ..." and walk right in, not flashing a photo id card or getting my keys out or anything requiring me to dig around in error-prone memory banks. 1 Actually I don't even want to have to say what my name is. The doorman should just say "Hey Matt, how are ya today?" as I breeze by (unless he's new, in which case verbal introductions are okay).

Whether that is accomplished in .htpasswd or a cookie jar or over a beer stein is irrelevant to me.

-- MattWilkie - 18 Dec 2003

Bumping Feature topic marked as Scheduled for CairoRelease that hasn't been modified recently.

-- SamHasler - 20 Apr 2004

I can't seem me completing this in the near future. therefore I'm defering its completion to Dakar

-- SvenDowideit - 17 Jun 2004