Last modified: 2012-02-03 13:06:58 UTC
A IP of de.wiki 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 de.wiki. [1] http://de.wikipedia.org/w/index.php?title=Simone_de_Beauvoir&diff=94101544&oldid=92622886
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 http://noc.wikimedia.org/conf/CommonSettings.php.txt $wgCaptchaWhitelist needs changing for protocol-relative URLs -> Using this as shell bug, changing summary and component.
Done: - $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';
