I have 500 or so spambots and about 5 actual registered users on my wiki. I have used nuke to delete their pages but they just keep reposting. I have spambot registration under control using reCaptcha. Now, I just need a way to delete/block/merge about 500 users at once.
preguntado el 22 de mayo de 12 a las 17:05
You could just delete the accounts from the
user table manually, or at least disable their authentication info with a query such as:
UPDATE /*_*/user SET user_password = '', user_newpassword = '', user_email = '', user_token = '' WHERE /* condition to select the users you want to nuke */
/*_*/ con tu
$wgDBprefix, if any. Oh, and do make a backup first.)
user_newpassword fields prevents the user from logging in. Also wiping out
user_email prevents them from requesting a new password via email, and wiping out
user_token drops any active sessions they may have.
Actualizar: Since I first posted this, I've had further experience of cleaning up large numbers of spam users and content from a MediaWiki installation. I've documented the method I used (which basically involves first deleting the users from the database, then wiping out up all the now-orphaned revisions, and finally running rebuildall.php to fix the link tables) in this answer on Webmasters Stack Exchange.
Alternatively, you might also find Extension:RegexBlock útil:
"RegexBlock is an extension that adds special page with the interface for blocking, viewing and unblocking user names and IP addresses using regular expressions."
There are risks involved in applying the solution in the accepted answer. The approach may damage your database! It incompletely removes users, doing nothing to preserve referential integrity, and will almost certainly cause display errors.
I have a little awkward way to accomplish the bulk merge through a work-around. Hope someone would find it useful! (Must have a little string concatenation skills in spreadsheets; or one may use a python or similar script; or use a text editor with bulk replacement features)
Prepare a list of all SPAMuserIDs, store them in a spreadsheet or textfile. The list may be prepared from the user creation logs. If you do have the dB access, the Wiki_user table can be imported into a local list.
The post method used for submitting the Merge & Delete User form (by clicking the button) should be converted to a get method. This will get us a long URL. See the second comment (by Matthew Simoneau) dated 13/Jan/2009) at http://www.mathworks.com/matlabcentral/newsreader/view_thread/242300 for the method. The resulting URL string should be something like below:
http: //(Your Wiki domain)/Special:UserMerge?olduser=(OldUserNameHere)&newuser=(NewUserNameHere)&deleteuser=1&token=0d30d8b4033a9a523b9574ccf73abad8%2B\
Now, divide this URL into four sections:
A: http: //(Your Wiki domain)/Special:UserMerge?olduser= B: (OldUserNameHere) C: &newuser=(NewUserNameHere)&deleteuser=1 D: &token=0d30d8b4033a9a523b9574ccf73abad8%2B\
Now using a text editor or spreadsheet, prefix each spam userIDs with part A and Suffix each with Part C and D. Part C will include the NewUser(which is a specially created single dummy userID). The Part D, the Token string is a session-dependent token that will be changed per user per session. So you will need to get a new token every time a new session/batch of work is required.
With the above step, you should get a long list of URLs, each good to do a Merge&Delete operation for one user. We can now create a simple HTML file, view it and use a batch downloader like DownThemAll in Firefox. Add two more pieces " Linktext" to each line at beginning and end. Also add at top and at bottom and save the file as (for eg:) userlist.html
Open the file in Firefox, use DownThemAll add-on and download all the files! Effectively, you are visiting the Merge&Delete page for each user and clicking the button!
Although this might look a lengthy and tricky job at first, once you follow this method, you can remove tens of thousands of users without much manual efforts.
You can verify if the operation is going well by opening some of the downloaded html files (or by looking through the recent changes in another window).
One advantage is that it does not directly edit the MySQL pages. Nor does it require direct database access.
I did a bit of rewriting to the quoted text, since the original text contains some flaws.