1008487 - Install ConfirmAccount extension on wiki.mozilla.org

Status: VERIFIED FIXED

(Infrastructure & Operations :: IT-Managed Tools, task)

Description

[Christie Koehler [:ckoehler]]

Today well over 500 spam user accounts were created on the wiki. 

I'd like to get the ball rolling on installing the ConfirmAccount extension:
https://www.mediawiki.org/wiki/Extension:ConfirmAccount

I will work on gathering a list of bureacrats who will agree to approve requests quickly. Will also file a request for a security review of the extension.

Comment 1

[Jake Maul [:jakem]]

I've deployed this to wiki-dev.allizom.org (though we still need to get the go-ahead from OpSec before we can go to production).

2 questions:

1) Any preference on $wgAccountRequestMinWords? Default is to require a 50-word biography to make an account.

2) Any preference on how this should tie in to the ConfirmEdit settings - namely the captcha on the new user signup page?


You can make accounts in the usual way, and then anyone with bureaucrat permissions can approve/deny them here:

https://wiki-dev.allizom.org/Special:ConfirmAccounts

Comment 2

[Jake Maul [:jakem]]

Thanks Yvan!

Christie: I've deployed and activated this to both wiki-dev.allizom.org and wiki.allizom.org. Works for me... the UX is actually rather nice... not pretty so much as informative and obvious.

I have deployed it to wiki.mozilla.org, but not activated it there, as I didn't want to start breaking new signups until we've got a list of bureaucrats signed up to do the approvals. Let me know when you're ready to go on that.

Comment 3

[Christie Koehler [:ckoehler]]

$wgAccountRequestMinWords should be set to '10';

Can you also set the following?

$wgConfirmAccountRequestFormItems = array(
	# Let users make names other than their "real name"
	'UserName'        => array( 'enabled' => true ),
	# Real name of user
	'RealName'        => array( 'enabled' => true ),
	# Biographical info
	'Biography'       => array( 'enabled' => true, 'minWords' => 10 ),
	# Interest checkboxes (defined in MediaWiki:requestaccount-areas)
	'AreasOfInterest' => array( 'enabled' => false),
	# CV/resume attachment option
	'CV'              => array( 'enabled' => false),
	# Additional non-public info for reviewer
	'Notes'           => array( 'enabled' => true ),
	# Option to place web URLs that establish the user
	'Links'           => array( 'enabled' => true ),
	# Terms of Service checkbox
	'TermsOfService'  => array( 'enabled' => false),
);

Once this is on dev and stage we'll test again.

Comment 4

[Jake Maul [:jakem]]

Deployed on wiki-dev.allizom.org and wiki.allizom.org. Let me know if/when we're ready to do the same on Prod.

Comment 5

[Christie Koehler [:ckoehler]]

I'm not seeing these changes reflected on either stage or dev.

Comment 6

[Christie Koehler [:ckoehler]]

I probably gave you conf details for the wrong version of the plugin. 

Please remove the code from comment 3 and add the following:

$wgUseRealNamesOnly = false;
$wgAccountRequestMinWords = 10;
$wgAccountRequestToS = false;
$wgAllowAccountRequestFiles = false;

Note: I've only included properties that should be changed from their default.

Comment 7

[Jake Maul [:jakem]]

Ah, I see... the $wgConfirmAccountRequestFormItems setting is not available until the version that works with MediaWiki 1.20 and above. We're on 1.19.

There are some similar (though not identical) settings available. Here's what I've set:

$wgAccountRequestMinWords = 10;
# Make the username of the real name?
$wgUseRealNamesOnly = false;
$wgAccountRequestToS = false;
$wgAllowAccountRequestFiles = false;

This seems to be as close as I can get to what you requested. It's deployed to dev and stage.


Here's what the default config looks like on the version we're using (branch 'REL1_19', for reference): 

http://git.wikimedia.org/blob/mediawiki%2Fextensions%2FConfirmAccount.git/32a03710c9b55e5d2391d55822bfa0ddcb5734fa/ConfirmAccount.config.php

Comment 8

[Jake Maul [:jakem]]

Hah! jinx!

Let me know if it's good to go to prod now. :)

Comment 9

[Christie Koehler [:ckoehler]]

Okay, this seems to be working okay. However, I'd like to adjust the following:

# How many requests can an IP make at once?
$wgAccountRequestThrottle = 1;

This needs to be a higher number since it's completely reasonable that different people will be requesting accounts under the same public IP address. Not sure what a reasonable value is, though. 25? 50? 100?

Let's also email WikiMo admins once someone who's requested an account confirms their email. 

# Send an email to this address when account requestors confirm their email.
# Set to false to skip this
$wgConfirmAccountContact = '[e-mail]';

Comment 10

[Jake Maul [:jakem]]

Deployed to dev and stage... I don't know what's reasonable either, might depend on how fast we are at confirming accounts. I'm okay with starting at 50.

One way to get closer might be to try to estimate how many account requests we get in whatever time period we think someone would review and approve/reject them all. Then from that, take a stab at how many unique IPs are represented. Trouble is, with this in place, I expect our spam account requests to drop drastically (I imagine that far fewer spam bots, and far fewer humans, are likely to even try)... so our current stats might be very different from what we'd have here.

I'm content to just start and see where we end up. The default of 1 is problematic for testing, but I wouldn't be surprised if a pretty low number is reasonable once we get going.

Comment 11

[Christie Koehler [:ckoehler]]

FYI things look good on dev and stage. I've identified administrators in timezomes spanning UTC-7 through UTC+2 who will help approve accounts. Will work on getting specific coverage for Asia. 

I've also drafted and am circulating for review an announcement of the change. 

We should be good to roll this out on Friday, but please wait to do so until I update the bug indicating as much. Thanks!

Comment 12

[Christie Koehler [:ckoehler]]

Ready to enable this in production!

Comment 13

[Jason Crowe [:jd]]

This has been deployed to prod. Please let us know if you run into any errors.

Cheers