How to remove users
See UserAdmin
I would like to share with you some thoughts on the problem of how to remove registered users.
This has maybe little interest for traditional wikis (meant to be collaborative tools with unrestricted access), but is certainly relevant for many other possible uses of a wiki engine (e.g. a moderated or members-only CMS)
Why on earth should I want to delete a user?
There are cases in which a wikka administrator might be willing to delete a user:
- spammers - users that exploit wikis as link farms for boosting their websites;
- vandals - users removing whole pages just for fun;
- fake users - users who created a "throw-away" account just for testing the wikiengine;
- obsolete users - depending on the use of a wiki, there are cases in which users become inactive after a certain time (imagine a wiki engine used as an intranet tool for a group/organization whose members are renewed every year and in which content is reset every year).
So far, the only way to remove users is to manually delete entries from the wikka_users table, which raises some major problems (see below) and requires some basic knowledge of MySQL/phpmyadmin.
I think that a wiki-based system for managing user deletion might interest many potential wiki administrators.
Problems with user deletion
Removing users has a number of consequences similar to removing pages. Wiki users are not atoms, they are embedded at different levels in a wiki engine: they appear in the history of wiki pages as contributors or page owners, in comments, in ACL lists etc.
Simply deleting an entry in the user table leaves won't help remove their 'presence' from the wiki and can create inconsistencies in the wiki.
Active/inactive users
A possible way to avoid the problems above is to think of user deletion as user inactivation, i.e. handling a list of active users and inactive users (much as valid vs. blacklisted referrers). This solution has a number of benefits:
- Removing users takes just one click to shift them from the active to the inactive list.
- Users can be reactivated on demand: their logs and pages are still available in the database.
- The overall consistency of the wiki is saved. One just needs to implement a function that checks the status of a user (active/inactive) before performing operations like displaying a page content, a comment or an ACL interface. This should be discussed in
Banning users by IP
A different but related issue concerns the possibility to remove users not by username but by IP address. This might be useful in the case of vandals or spammers that can create an infinite number of useraccounts. Requiring email validation on registration can be a good solution, but perhaps the best solution would be to store the IP of the last connection in a dedicated field of the wikka_users table. Dozens of users connected from the same IP address might draw the Wikka administrator's attention;
Any ideas/thoughts on these issues before I start toying with some code?
-- DarTar
A few thoughts...
Why on earth should I want to delete a user?
- Spammers: During my recent Wiki rambles I found some good throughts on WikiSpam, discovered Fighting back against wiki and blog spam and many other pages on this subject. Basically, there are many ways to fight back, but an important way is to discourage WikiSpam in the first place, by making sure that 1) Page History and RecentChanges are out of bounds to all search engine robots, and 2) do the same for the SandBox: just insert the appropriate meta tag, and leave a note on those pages. Another approach I've seen is to lead all external links through Google's own redirector but of course this works only to prevent indexing by Google and not (necessarily) other search engines. The more spammers are discouraged, the less you'll have to do about them.
- Vandals: Should be "banned" as well as "deleted". How, is the question. Reverting a vandalized page isn't quite enough; I was thinking about a "de-deface" action for a WikiAdmin which would 1) set the "current" flag to the previous page version as well as 2) delete the defaced page version. The Wiki community could just revert but it takes a number of actions to do that; a special action for a WikiAdmin could be faster and more thorough by not "leaving a trace" of the vandalism in the first place. (But see also the remarks above about denying access to SE bots to history and changes.) In principle, fast action on defacement will discourage the vandals - from what I've read it seems to work.
- Fake users and Obsolete users I would consider these as two variants of "inactive users". The Mantis bug-tracking system has a "purge" action for the administrator that deletes accounts of users who have created an account but never logged in (after a certain -configurable- period); I could imagine something similar for Wikka. Something along the lines of automatically setting a user as "inactive" after a period of "inactivity". Needs more thought on how this would apply, exactly...
Problems with user deletion
I quite agree this would be a problem if done directly (manually) on the users database - unless the user has never actually created or edited any content (not even comments). Otherwise inconsistency of the database could easily result; should be avoided unless you really know what you are doing and have intimate knowledge not only of the database structure but also how it is used.Active/inactive users
I like this a lot better - and see also my remark about "fake" and "obsolete" users above: making some users automatically "inactive"."Users can be reactivated on demand" - actually I think an "inactive" user should be allowed to login (anyway) and be automatically be "activated" again once s/he actually edits or contributes content (or at least content other than comments). This requires more thought about a precise mechanism, but my idea is that for "naturally" inactive users, inactivation and activation should be automatic and dependent on "behavior" so that only spammers and vandals would really require action by a WikiAdmin.
(If I go on vacation for more than two months --and that happens :)-- I might be temporarily "inactive" but as soon as I'm back and actually do something to a Wiki, I would be "active" again. On some larger and well-established Wikis people might actually be "inactive" for a year or more, and then return because they feel they can/should make a contribution again.)
Banning users by IP
BIG RED FLAG. There might be cases where this is necessary, but it really should be a desperate last resort, IMO. Why? Because an IP address does not necessarily identify a user. First, most dial-up users and many broadband users will get a new IP address each time they establish a new connection. In addition, many large access providers (AOL is one notorious example, but by no means the only one) don't have enough IP addresses even dynamically (by connection) to go around their number of users: what they do is give a new IP address for every request sent to a server (the proxy server on their network effectively does that). And then there are the corporate networks that internally have many isers, but externally (as their interface to the Internet) display only a single IP address. As a result (mostly due to the scarcity of IP addresses under ""IPv4"), a single IP address may be used by many users, and a single user may have multiple IP addresses even during a single session. Banning by IP address could thus result in banning a multitude of people, or a multitude of people only part of the time. Rarely effective, and often victimizing completely innocent users. This wouldn't matter all that much for a little informal poll, trying to prevent people from voting twice; but for denying access it's not practical, not user-friendly, and will often mis-fire."Requiring email validation on registration can be a good solution." Only partly, I think; and it would also make a Wiki even less "open" than one that doesn't even require registration to get "edit" rights. It might be valid for some Wikis, but at the very least it should be a configuration option.
Thanks for bringing this up though, DarTar! I had been thinking about some of these isseus already. I hope to see more discussion on this!
-- JavaWoman
My two pennies
I would also like the ability to remove users. From my point of view, I am using the wiki on a corporate Intranet and what with people leaving and being made redundant :-( I want to be able to tidy up the users (of course if I am one of those being made redundant, I won't be that bothered any more!). I don't see too many problems with removing them from the users table if at the same time the ownership of any of their pages is transferred to another user. The history of the pages is still valid as you store the user name and not an id, so you can still see that they edited a page even though they are no longer in the user table. You could at the same time delete their user page (and all revisions). The biggest problem that I see is when you start using other features that are not included in the standard wiki release e.g. PageWatches, where you are notified by email if a watched page changes; the user would have to be removed from this table as well. This is where the real inconsistencies in the database could occur. For this reason, having an active/inactive flag would seem the better way to go, then anyone writing new features or modifying existing ones can take the flag into consideration.Email validation
I really would like to see the email validation on registration as a feature (this time not for a corporate intranet, but for my own web site), and I agree that this should be a configuration option. Anyone who seriously wants to contribute to a wiki would have no problem waiting a few minutes for a validation email, whereas a vandal would probably be put off. If they are still willing to vandalise or spam after being validated, their email address could be used to ban them.--PeeJay
This has been enlightening. I found this page trying to figure out why my UserAdmin delete function did not work. The fact that this page has not been address in nearly 5 months is hopefully not an indication that user deletion is abandoned.
I agree with many of PeeJay's comments. My wiki is used to develop training material. I already have need to delete a duplicate user account (well not exact duplicate but it's the same user). The idea of keeping the user list cleaned up is something important to me.
I hope I don't have a problem with vandals. If I did, the ability to block their email address and reset all of their changes (as it they never entered the site in the first place, would be highly desirable.
--MikeBev
CategoryDevelopmentAdmin
"registration_active" => "on"
to wikka.config.php
and then
$regactive = $this->GetConfigValue("registration_active");
as the top line of usersettings.php
and then inserted
($regactive == "on") &&
in someo of the if statements (like the first one) with an else printing "registration is closed" at the bottom.
That all allows registration to be "open" and if I change
"registration_active" => "off"
then they get the "registration is closed" message.
Nils also has a modification somewhere here, that works really well, that requires a password to register that is set in wikka.config.php.
Hope this helps. (I can't just post my file because it is considerably modified other than that)
mike b
Pietro, you could use the code provided by Mike, our take a look at UserRegistration - both methods allow you to disallow registration
However, wikka uses cookies, and if a login cookie is on your machine, you're logged in as long as that cookie exists, right? That means if has cookies enabled, he'll still basically have access, won't he? Short of going through and restricting his write access to all 300 pages, is there a way I can disable his cookie, or the user entirely?
I've already made 1 change to the UserSettings page that requires the user to enter a second password in order to register a new account - that password is given to the student by a teacher. It's a bit of a hack at the moment and I need to do some more work (there is just a single password hard coded into the UserSettings page - to get things moving :) ).
Deletion of users would be helpful, but having poked about in the database, it is obvious that it could cause problems.
My intention is to write something that will allow me to "deactivate" a user, randomising their password and putting in a fake email address so they can't retrieve it and I think that will do the job I need.
First though, I have a LOT of php to get my head around :)
This feature will be included with the next stable release (1.1.7).
As for deletion of a registered user, I think the most sensible strategy is to deactivate the user by adding an extra field in the user table and then filter content retrieved from the DB so that contributions (comments or revisions) from inactive users are not displayed (but stored in the DB for reference).
Having installed UserAdmin, my first question is this: If UserAdmin shows zero pages, zero edits and zero comments, is there any data inside SQL it's not showing that might still mess up the database if I delete these users by hand? (I should ask this question twice; once for totally unused accounts, and once for accounts whose contributions have been systematically erased.) I have a fresh install of the wiki with several mods installed but none that add SQL tables.
My second question is: Since a PHP-based delete routine seems unlikely to be written (unless it could be made less harmful by performing the checks for the data I described above?), is someone willing to point me at what data I would need to delete by hand inside MySQL? I would only be doing it to empty accounts after a database backup, and I take full responsibility.
As for your second question, have you got something like phpMyAdmin to access your DB?
Thanks for the welcome, and I do hope to pitch in (even if only by following up and possibly improving ways to safely delete unused accounts). :)