r70919 MediaWiki - Code Review archive

In conversion_log.php and recaptcha.php: same comments here as to standard MW extension style as in minfraud.php. Set $wgHooks in the extension setup file, don't make the user do it. Don't create objects before MW is fully set up and the relevant functionality is required. Defer the loading of as much code as possible using the autoloader.

		$this->display_captcha( &$pfp_gateway_object, &$data );

Using ampersands in function calls to force arguments to be references is deprecated and will generate a warning in PHP 5.3.0+, see http://www.php.net/manual/en/language.references.pass.php . You should use an ampersand only in the function declaration. I think there were some more examples of this elsewhere in your code, you should fix it everywhere.

Fixed in r71725

You will need to change this to use recaptchalib directly. The MediaWiki reCAPTCHA plugin bundles its own copy of ConfirmEdit, which will conflict with the ConfirmEdit already installed on Wikimedia websites. Including the extension setup file for the MW reCAPTCHA extension has unintended consequences, such as adding a captcha to edit and account creation forms. The code here will be basically the same: the MW plugin is a very thin wrapper around recaptchalib, basically the only things it adds are things we don't want.

Fixed in r71735

Has Wikimedia's position on reCAPTCHA changed? http://en.wikipedia.org/w/index.php?title=Wikipedia:Perennial_proposals&oldid=379804296#Use_reCAPTCHA

In this particular case (the credit card gateway in the Foundation's fundraising system), reCaptcha (or any other captcha solution we might use) will only be seen by a small minority of users.

If we could find an open source PHP captcha solution that works as well as reCaptcha, I'd love to use it instead. However, the existing solutions that I've been able to find have weaknesses that are exploitable while reCaptcha does not. Because of the sensitivity of the data going through our credit card processing pipeline and the need to reduce fraudulent uses of our gateway, this is of particular concern. We've also ruled out using the FancyCaptcha solution that's packaged with the ConfirmEdit extension because of the Python dependency and the issues that come with that (http://www.mediawiki.org/wiki/Extension:ConfirmEdit#How_to_avoid_common_problems_running_Python).

For these reasons (plus reCaptcha's free culture roots) make reCaptcha the current logical choice for this particular implementation.

If someone were willing to port FancyCaptcha to natively use PHP or someone found a reasonable, php-based open source captcha solution that provided the same (or better) level of security as reCaptcha, we'd love to use it.

> We've also ruled out using the FancyCaptcha solution that's packaged with the ConfirmEdit extension because of the Python dependency and the issues that come with that > If someone were willing to port FancyCaptcha to natively use PHP or someone found a reasonable, php-based open source captcha solution that provided the same (or better) level of security as reCaptcha, we'd love to use it.

It's a working solution for us, already working in the servers.

From [1] only "does not work on new python versions" seems relevant, but that was fixed a year ago in r56008. It works fine here in 2.6.5.

You will need python + PIL, but that's what packages are for (and there's already a good bunch of generated images at the servers, but I understand you may want to use different ones).

It would obviously be nice to have that directly in php but rejecting python for favoring an external server is wrong IMHO.

You don't need to be able to use Python to use FancyCaptcha, you can just use the existing captcha directory which is available by NFS in the Wikimedia network. But in any case, it's not a problem to use Python at Wikimedia, we do lots of things with it.

As a closed-source project operated by a commercial entity, reCaptcha's "free culture roots" are well-hidden.

As I understand it, the reCAPTCHA CAPTCHA will only be displayed to users that trigger the fraud flag, so the external server dependency isn't much of an issue. If the reCAPTCHA servers went down, we might loose a small handful of donations, but that would be the worst case scenario. I think Arthur covered the other issues above. Given the options for this particular problem (both closed and open source), reCAPTCHA seems to be the best solution, especially given the timeframe that we need to get this into place by.