Last modified: 2014-11-12 14:47:37 UTC
$wgCaptchaTriggers['addurl'] defaults to true, so that if a user (new? not-confirmed?) adds an external link to a wiki page, he or she is prompted with a CAPTCHA: Your edit includes new external links. To protect the wiki against automated edit spam, we kindly ask you to answer the question that appears below (more info): But this doesn't happen for Flow posts or header edits, and it probably should. This may be a contributing factor to our recent spam attack.
The WMF core features team tracks this bug on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/flow/cards/704, but people from the community are welcome to contribute here and in Gerrit.
Change 138332 had a related patch set uploaded by Spage: [WIP] ConfirmEdit, captcha version https://gerrit.wikimedia.org/r/138332
Change 144664 had a related patch set uploaded by Matthias Mullie: ConfirmEdit, captcha version https://gerrit.wikimedia.org/r/144664
Change 138332 abandoned by Matthias Mullie: [WIP] ConfirmEdit, captcha version Reason: New patch at https://gerrit.wikimedia.org/r/#/c/144664/ https://gerrit.wikimedia.org/r/138332
Change 144664 merged by jenkins-bot: ConfirmEdit, captcha version https://gerrit.wikimedia.org/r/144664
This patch was merged, but there's an extensive commit message, which might need further bugs filed, so I'll paste that, and leave this bug open: ConfirmEdit, captcha version This will now display the captcha to be solved in the error message. Some caveats we may want to keep in the back of our heads: 1/ Biggest potential problem here is, upon successfully completing the submitted post (with ConfirmEdit solution), the API will respond that the ConfirmEdit params were unused. This happens because those params aren't requested via the API's designated getParameter methods (or even defined in the API's getAllowedParams). ConfirmEdit just fetches them from the Request object. Basically, this happens because I treat the ConfirmEdit implementation as not- API. It has *some* (very limited) API stuff that I *could* use (if I modified ConfirmEdit a bit). However, ConfirmEdit's API part doesn't render the form, so that would be left up to us (= Flow), which is something I don't want to have to do, since there are multiple Captcha types. So basically, due to how this is implemented, the API will always respond with a warning after succesfully submitting the correct captcha solution. That warning won't affect anything, but might potentially be confusing to bot authors. 2/ Along with the captcha form HTML, some captcha implementations need some CSS/JS. Those are extracted from $wgOut & responded along with the form HTML. There's no arguing that this is not the best kind of programming, but since ConfirmEdit is messy, has multiple different implementations & completely outside of Flow, this currently seems to be the best solution. And it works ;)
[All related patches merged or abandoned; resetting bug report status.]
