Page MenuHomePhabricator

Flow: adding external links should trigger CAPTCHA
Closed, ResolvedPublic

Description

$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.


Version: master
Severity: normal

Details

Reference
bz59835

Event Timeline

bzimport raised the priority of this task from to High.
bzimport set Reference to bz59835.
bzimport added a subscriber: Unknown Object (MLST).
Spage created this task.Jan 8 2014, 9:34 PM

bingle-admin wrote:

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

Quiddity added a comment.EditedAug 1 2014, 6:18 AM

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.]

Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptApr 6 2015, 8:35 PM
Mattflaschen-WMF closed this task as Resolved.Aug 19 2015, 5:50 AM
Mattflaschen-WMF assigned this task to matthiasmullie.
Mattflaschen-WMF set Security to None.