Page MenuHomePhabricator

allow protocol-relative URLs in $wgCaptchaWhitelist
Closed, ResolvedPublic


A IP of was telling, that he get a CAPTCHA for a edit, where only a comma is changed[1].

In my opinion is this a problem with protocol-relative URLs.

The page includes a fullurl to commons. Before the edit the database contains a http link to commons, after the reparse due to the edit the link to commons is changed to a protocol-relative URL and ConfirmEdit is seeing a different and trigger the CAPTCHA -> bad in this case.

We can fix this by editing all templates with fullurl to trigger a reparse with the Job Queue, but that sounds like many load for the server and also fixed that problem only on


Version: unspecified
Severity: major



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:51 PM
bzimport set Reference to bz31294.

Juergen wrote:

Shouldn't we allow external links to commons from IP Users without a captcha, even when they are really new and not caused by protocol-relative URLs as explained by Umherirrender ?

This mechanism seems to be working already in the case of external links to WP (for instance for links like the diff-link from the description).

Links to Commons already allowed, when there are containing http or https at the begin. See $wgCaptchaWhitelist in

$wgCaptchaWhitelist needs changing for protocol-relative URLs
-> Using this as shell bug, changing summary and component.


  • $wgCaptchaWhitelist = '#^https?://([.a-z0-9-]+\\.)?((wikimedia|wikipedia|wiktionary|wikiquote|wikibooks|wikisource|wikispecies|mediawiki|wikimediafoundation|wikinews|wikiversity)\.org|dnsstuff\.com|completewhois\.com|wikimedia\.de|toolserver\.org)(/|$)#i';

+ $wgCaptchaWhitelist = '#^(https?:)?//([.a-z0-9-]+\\.)?((wikimedia|wikipedia|wiktionary|wikiquote|wikibooks|wikisource|wikispecies|mediawiki|wikimediafoundation|wikinews|wikiversity)\.org|dnsstuff\.com|completewhois\.com|wikimedia\.de|toolserver\.org)(/|$)#i';