⚓ T20110 Define AbuseFilter consequence

⚓ T20110 Define AbuseFilter consequence to display a CAPTCHA
Page Menu
Phabricator
Create Task
Maniphest
T20110
Define AbuseFilter consequence to display a CAPTCHA
Closed, Resolved
Public
Feature
Actions
Edit Task
Edit Related Tasks...
Create Subtask
Edit Parent Tasks
Edit Subtasks
Merge Duplicates In
Close As Duplicate
Edit Related Objects...
Edit Commits
Edit Mocks
Mute Notifications
Protect as security issue
Assigned To
kostajh
Authored By
bzimport
Mar 23 2009, 2:35 AM
2009-03-23 02:35:00 (UTC+0)
Tags
AbuseFilter
(Backlog)
Wikimedia-Hackathon-2024
(Hacking projects)
ConfirmEdit (CAPTCHA extension)
(Backlog)
MW-1.43-notes (1.43.0-wmf.14; 2024-07-16)
Trust and Safety Product Sprint (Sprint Theremin (Aug 26 - Sept. 6))
(Done)
User-notice-archive
(Backlog)
MW-1.44-notes (1.44.0-wmf.8; 2024-12-17)
Referenced Files
F57060567: abusefilter_discussiontools.png
Aug 5 2024, 9:59 AM
2024-08-05 09:59:13 (UTC+0)
F57060565: abusefilter_ve.png
Aug 5 2024, 9:59 AM
2024-08-05 09:59:13 (UTC+0)
Subscribers
Aklapper
Beetstra
Catrope
Cenarium
codenamenoreste
Daimona
DanielFriesen
View All 31 Subscribers
Description
Context
AbuseFilter provides the ability to define
consequences
in response to triggers. These are currently things like block, deny action, etc. It would be nice to define a consequence to show a CAPTCHA via the ConfirmEdit extension, for cases where the AbuseFilter exists to deny bot editing.
Proposal
Introduce a CaptchaConsequence that can be used for actions in AbuseFilter
Users with
skipcaptcha
right can continue to bypass CAPTCHA even if they trigger the AbuseFilter
Consequences
It is possible to configure AbuseFilters that show a CAPTCHA when conditions are matched
Next steps
Complete QA
Enable on all wikis
Original report
Author:
mike.lifeguard+bugs
Description:
To either slow down human abusers or weed out bots, please allow AbuseFilter to present a CAPTCHA & allow the change only if solved. Yes, I'm aware that captchas are mean to humans both blind and sighted (though of course a particular horror from an accessibility standpoint) - they'd have to be used sparingly etc, but that's a useful option IMO.
Version
: unspecified
Severity
: enhancement
Details
Reference
bz18110
Related Changes in Gerrit:
Subject
Repo
Branch
Lines +/-
ConfirmEditHandler: Remove method_exists checks
mediawiki/extensions/AbuseFilter
REL1_43
+0
-6
ConfirmEditHandler: Remove method_exists checks
mediawiki/extensions/AbuseFilter
master
+0
-6
AbuseFilter: Enable showcaptcha consequence everywhere
operations/mediawiki-config
master
+1
-2
SimpleCaptcha: Show captcha-edit message if forceShowCaptcha is set
mediawiki/extensions/ConfirmEdit
master
+18
-1
ConfirmEdit: Enable showcaptcha action on testwiki and beta wikis
operations/mediawiki-config
master
+11
-0
SimpleCaptcha: Allow invoking CAPTCHA display from other extensions
mediawiki/extensions/ConfirmEdit
master
+110
-24
ConfirmEditHandler: Use SimpleCaptcha API to invoke CAPTCHA display
mediawiki/extensions/AbuseFilter
master
+94
-27
AbuseFilterHooks: Provide feature flags for AF custom actions
mediawiki/extensions/ConfirmEdit
wmf/1.43.0-wmf.5
+24
-5
AbuseFilterHooks: Provide feature flags for AF custom actions
mediawiki/extensions/ConfirmEdit
master
+24
-5
CaptchaConsequence: Use SessionManager to communicate with AbuseFilter
mediawiki/extensions/ConfirmEdit
master
+20
-9
ConfirmEditHandler: Use Session instead of WebRequest
mediawiki/extensions/AbuseFilter
master
+20
-6
Provide integration with ConfirmEdit to show CAPTCHA
mediawiki/extensions/AbuseFilter
master
+65
-0
Allow showing a CAPTCHA in response to AbuseFilter consequence
mediawiki/extensions/ConfirmEdit
master
+99
-3
zuul: Update AbuseFilter/ConfirmEdit phan and test dependencies
integration/config
master
+5
-3
zuul: Add ConfirmEdit to phan dependencies for AbuseFilter
integration/config
master
+2
-1
Show related patches
Customize query in gerrit
Related Objects
Search...
Task Graph
Mentions
Duplicates
Status
Subtype
Assigned
Task
Resolved
Feature
kostajh
T20110
Define AbuseFilter consequence to display a CAPTCHA
Resolved
matmarex
T22661
Conflict between the Abuse Filter and the Captcha
Resolved
Daimona
T239348
Custom actions should always be included in the list of available actions
Mentioned In
T373797: Make it possible to silence "high rate of matches" AbuseFilter notifications
T373422: jQuery.Deferred exception: this.setSaveErrorMessage is not a function
T372642: Create a "Challenge" type subtype of "Consequence"
T357779: Provide ability to require temporary account users to complete a CAPTCHA in certain circumstances
T303433: Allow Stewards to enable 'emergency CAPTCHAs' for anonymous IP edits
T365973: API query module to show order of installed extensions
T361975: [Session] 🥳 Wikimedia Hackathon 2024 Project Showcase & Closing
T364710: Create AbuseFilter condition for "likely a bot"
T357778: Provide ability to require logged-out users to complete a CAPTCHA on temporary account creations in certain circumstances
T241921: Fix Wikimedia captchas
T13880: Captchas for new editors/anons making large edits
T43522: Provide a log of actions which trigger the CAPTCHA
Mentioned Here
T372642: Create a "Challenge" type subtype of "Consequence"
T303433: Allow Stewards to enable 'emergency CAPTCHAs' for anonymous IP edits
T151116: After passing the CAPTCHA page after warning, user is sent back to the Abuse Filter warning page
T69936: Provide a useable way to bypass abuse filters
T215136: Disabling an AbuseFilter action does not remove that action from existing filters
T135668: Need documentation on How to integrate AbuseFilter with xyz extension
T43522: Provide a log of actions which trigger the CAPTCHA
Duplicates Merged Here
T28765: Add option to require CAPTCHA to perform edit
T236760: Make captcha an option in the abusefilter
T33989: Allow AbuseFilter filters to trigger a CAPTCHA
Event Timeline
There are a very large number of changes, so older changes are hidden.
Show Older Changes
suffusion_of_yellow
added a comment.
Edited
May 14 2024, 7:15 PM
2024-05-14 19:15:11 (UTC+0)
Comment Actions
Hey, noticed on testwiki that some of you are trying this from your main account; that probably has
skipcaptcha
rights so will never be shown one.
FWIW, I
have also tried this
on your patch demo, and also get no captcha. Also tried on a local wiki, and again get no captcha. I even tried loading AbuseFilter
before
ConfirmEdit (a bad idea, breaks the "throttle" filters and also causes
T151116
), and still no luck.
gerritbot
added a comment.
May 14 2024, 7:46 PM
2024-05-14 19:46:44 (UTC+0)
Comment Actions
Change #1031549 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):
[mediawiki/extensions/ConfirmEdit@master] CaptchaConsequence: Use SessionManager to communicate with AbuseFilter
gerritbot
added a project:
Patch-For-Review
May 14 2024, 7:46 PM
2024-05-14 19:46:45 (UTC+0)
Comment Actions
Change #1031550 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):
[mediawiki/extensions/AbuseFilter@master] ConfirmEditHandler: Use Session instead of WebRequest
kostajh
added a comment.
May 14 2024, 7:51 PM
2024-05-14 19:51:50 (UTC+0)
Comment Actions
In
T20110#9796913
@suffusion_of_yellow
wrote:
Hey, noticed on testwiki that some of you are trying this from your main account; that probably has
skipcaptcha
rights so will never be shown one.
Yeah, I realized that and switched to using a logged out user for the test. Thanks for flagging though, it's easy to forget about that!
FWIW, I
have also tried this
on your patch demo, and also get no captcha. Also tried on a local wiki, and again get no captcha. I even tried loading AbuseFilter
before
ConfirmEdit (a bad idea, breaks the "throttle" filters and also causes
T151116
), and still no luck.
Thanks for that. I've uploaded an alternative approach that I think would be more robust.
suffusion_of_yellow
added a comment.
Edited
May 14 2024, 8:10 PM
2024-05-14 20:10:47 (UTC+0)
Comment Actions
In
T20110#9797066
@kostajh
wrote:
Thanks for that. I've uploaded an alternative approach that I think would be more robust.
Tried that on my local wiki (all edits made logged out):
Loading ConfirmEdit before AbuseFilter (the same order as WMF wikis), I get no captcha on the first attempted edit. I
do
get a CAPTCHA, the
next
time I open a page for editing, even before I try to publish.
Loading AbuseFilter before ConfirmEdit, I get a "Incorrect or missing CAPTCHA. " error (even though I would have had no idea a CAPTCHA was to be expected). Also, the message is at the top, but the CAPTCHA entry form is at the bottom. But reversing the order would be a very bad idea; it would cause "throttle" filters to trip on innocent users struggling with the CAPTCHA, and also prevent any user from adding an external link, if they also trip a "warn" filter.
kostajh
added a comment.
Edited
May 14 2024, 8:23 PM
2024-05-14 20:23:03 (UTC+0)
Comment Actions
In
T20110#9797176
@suffusion_of_yellow
wrote:
In
T20110#9797066
@kostajh
wrote:
Thanks for that. I've uploaded an alternative approach that I think would be more robust.
Tried that on my local wiki (all edits made logged out):
Loading ConfirmEdit before AbuseFilter (the same order as WMF wikis), I get no captcha on the first attempted edit. I
do
get a CAPTCHA, the
next
time I open a page for editing, even before I try to publish.
Loading AbuseFilter before ConfirmEdit, I get a "Incorrect or missing CAPTCHA. " error (even though I would have had no idea a CAPTCHA was to be expected). Also, the message is at the top, but the CAPTCHA entry form is at the bottom. But reversing the order would be a very bad idea; it would cause "throttle" filters to trip on innocent users struggling with the CAPTCHA, and also prevent any user from adding an external link, if they also trip a "warn" filter.
Aha. Yeah, I am loading AbuseFilter before ConfirmEdit in my local wiki. Thank you for testing the patches and leaving the detailed notes. OK, I'll look at this more closely tomorrow.
Daimona
added a comment.
May 14 2024, 8:23 PM
2024-05-14 20:23:49 (UTC+0)
Comment Actions
Alternatively, would it be possible to set a static flag in one of the ConfirmEdit classes? In theory, it doesn't even need to be static as long as the class in question is obtained through the service container. Something like AbuseFilter's own
EditRevUpdater::$logIds
. Another thing is that this could live all within the ConfirmEdit extension, and the property might be read in
triggersCaptcha
directly, without using a hook.
suffusion_of_yellow
added a comment.
May 14 2024, 8:30 PM
2024-05-14 20:30:37 (UTC+0)
Comment Actions
Won't ConfirmEdit need to be run
twice
, though? Once before AbuseFilter, to avoid filter trips from repeated bad CAPTCHAs, then again after AbuseFilter iff (A) No CAPTCHA was show on the first run, and (B) A
showcaptcha
filter was tripped.
Daimona
added a comment.
May 14 2024, 8:32 PM
2024-05-14 20:32:45 (UTC+0)
Comment Actions
Yeah, just to clarify, my comment was only in response to the switch from WebRequest to Session. But indeed, it does not address the bug above, which seems to be due to the order of execution.
suffusion_of_yellow
added a comment.
May 14 2024, 9:39 PM
2024-05-14 21:39:27 (UTC+0)
Comment Actions
FWIW, I
have also tried this
on your patch demo, and also get no captcha.
Correction. I didn't realize that the "Type 'patchdemo' here as an anti-spam measure." box was coming from QuestyCaptcha, and thought it was some generic anti-spam measure on all patchdemos.
So what actually happened is that I
did
get a request for a CAPTCHA, but the box was there
before
I even tried to click "Publish"! This cannot be coming from AbuseFilter; the filters haven't even been checked yet. Do you have ConfirmEdit enabled for all edits with something like
$wgCaptchaTriggers['edit'] = true;
kostajh
added a comment.
May 15 2024, 6:15 AM
2024-05-15 06:15:59 (UTC+0)
Comment Actions
In
T20110#9791865
@kostajh
wrote:
Suggested text for user notice:
AbuseFilter can show a CAPTCHA to a user before they can proceed with an action. Not all actions may be supported, but the CAPTCHA action should work well for source and API edits. As this is a new action, please use with caution and report any issues as subtasks of
T20110
The user notice should wait, because the functionality isn't working yet in production.
gerritbot
added a comment.
May 15 2024, 6:29 AM
2024-05-15 06:29:04 (UTC+0)
Comment Actions
Change #1031757 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):
[mediawiki/extensions/ConfirmEdit@master] AbuseFilterHooks: Provide feature flags for AF custom actions
gerritbot
added a comment.
May 15 2024, 6:47 AM
2024-05-15 06:47:22 (UTC+0)
Comment Actions
Change #1031550
abandoned
by Kosta Harlan:
[mediawiki/extensions/AbuseFilter@master] ConfirmEditHandler: Use Session instead of WebRequest
Reason:
Doesn't fix the underlying issue, which is due to order of extension loading in production.
gerritbot
added a comment.
May 15 2024, 6:47 AM
2024-05-15 06:47:30 (UTC+0)
Comment Actions
Change #1031549
abandoned
by Kosta Harlan:
[mediawiki/extensions/ConfirmEdit@master] CaptchaConsequence: Use SessionManager to communicate with AbuseFilter
Reason:
Doesn't fix the underlying issue, which is due to order of extension loading in production.
Ladsgroup
added a comment.
Edited
May 15 2024, 9:09 AM
2024-05-15 09:09:24 (UTC+0)
Comment Actions
You could reorder the list of extensions to be loaded in production, it has been done before for the exact same problem but 1- It's not sustainable 2- it might break other things.
kostajh
added a comment.
May 15 2024, 9:17 AM
2024-05-15 09:17:16 (UTC+0)
Comment Actions
In
T20110#9798669
@Ladsgroup
wrote:
You could reorder the list of extensions to be loaded in production, it has been done before for the exact same problem but 1- It's not sustainable 2- it might break other things.
It will break other things.
I’m working on a patch that uses a different approach, will clean it up and push for review later today.
gerritbot
added a comment.
May 15 2024, 12:28 PM
2024-05-15 12:28:37 (UTC+0)
Comment Actions
Change #1031885 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):
[mediawiki/extensions/ConfirmEdit@master] [WIP] SimpleCaptcha: Allow invoking from other extensions
gerritbot
added a comment.
May 15 2024, 12:29 PM
2024-05-15 12:29:00 (UTC+0)
Comment Actions
Change #1031886 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):
[mediawiki/extensions/AbuseFilter@master] [WIP] ConfirmEditHandler: Use SimpleCaptcha to invoke CAPTCHA display
gerritbot
added a comment.
May 15 2024, 3:42 PM
2024-05-15 15:42:15 (UTC+0)
Comment Actions
Change #1031921 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):
[mediawiki/extensions/ConfirmEdit@wmf/1.43.0-wmf.5] AbuseFilterHooks: Provide feature flags for AF custom actions
gerritbot
added a comment.
May 15 2024, 4:22 PM
2024-05-15 16:22:09 (UTC+0)
Comment Actions
Change #1031757
merged
by jenkins-bot:
[mediawiki/extensions/ConfirmEdit@master] AbuseFilterHooks: Provide feature flags for AF custom actions
ReleaseTaggerBot
edited projects, added
MW-1.43-notes (1.43.0-wmf.6; 2024-05-21)
; removed
MW-1.43-notes (1.43.0-wmf.5; 2024-05-14)
May 15 2024, 5:00 PM
2024-05-15 17:00:35 (UTC+0)
Quiddity
moved this task from
To Triage
to
Not ready to announce
on the
User-notice
board.
May 15 2024, 6:40 PM
2024-05-15 18:40:28 (UTC+0)
gerritbot
added a comment.
May 15 2024, 8:59 PM
2024-05-15 20:59:03 (UTC+0)
Comment Actions
Change #1031921
merged
by jenkins-bot:
[mediawiki/extensions/ConfirmEdit@wmf/1.43.0-wmf.5] AbuseFilterHooks: Provide feature flags for AF custom actions
Stashbot
added a comment.
May 15 2024, 8:59 PM
2024-05-15 20:59:48 (UTC+0)
Comment Actions
Mentioned in SAL (#wikimedia-operations)
[2024-05-15T20:59:39Z] Started scap: Backport for [[gerrit:1031921|AbuseFilterHooks: Provide feature flags for AF custom actions (
T20110
)]]
ReleaseTaggerBot
edited projects, added
MW-1.43-notes (1.43.0-wmf.5; 2024-05-14)
; removed
MW-1.43-notes (1.43.0-wmf.6; 2024-05-21)
May 15 2024, 9:00 PM
2024-05-15 21:00:26 (UTC+0)
Stashbot
added a comment.
May 15 2024, 9:02 PM
2024-05-15 21:02:21 (UTC+0)
Comment Actions
Mentioned in SAL (#wikimedia-operations)
[2024-05-15T21:02:20Z] samtar and kharlan: Backport for [[gerrit:1031921|AbuseFilterHooks: Provide feature flags for AF custom actions (
T20110
)]] synced to the testservers (
Stashbot
added a comment.
May 15 2024, 9:16 PM
2024-05-15 21:16:11 (UTC+0)
Comment Actions
Mentioned in SAL (#wikimedia-operations)
[2024-05-15T21:16:10Z] Finished scap: Backport for [[gerrit:1031921|AbuseFilterHooks: Provide feature flags for AF custom actions (
T20110
)]] (duration: 16m 31s)
kostajh
mentioned this in
T365973: API query module to show order of installed extensions
May 27 2024, 9:35 AM
2024-05-27 09:35:32 (UTC+0)
kostajh
added a comment.
Jun 6 2024, 2:07 PM
2024-06-06 14:07:05 (UTC+0)
Comment Actions
In
T20110#9797662
@suffusion_of_yellow
wrote:
FWIW, I
have also tried this
on your patch demo, and also get no captcha.
Correction. I didn't realize that the "Type 'patchdemo' here as an anti-spam measure." box was coming from QuestyCaptcha, and thought it was some generic anti-spam measure on all patchdemos.
So what actually happened is that I
did
get a request for a CAPTCHA, but the box was there
before
I even tried to click "Publish"! This cannot be coming from AbuseFilter; the filters haven't even been checked yet. Do you have ConfirmEdit enabled for all edits with something like
$wgCaptchaTriggers['edit'] = true;
@suffusion_of_yellow
Yeah, Patch Demo isn't a good environment for verifying these patches because it sets a CAPTCHA for all edits for not logged-in users, and gives all logged-in users
skipcaptcha
right. We'd need to make some adjustments. The config it uses (
extensions-ConfirmEdit.php
):
$wgCaptchaTriggers
'edit'
true
$wgCaptchaTriggers
'createaccount'
true
// Don't show CAPTCHA when logged in
$wgGroupPermissions
'user'
][
'skipcaptcha'
true
I've reworked the functionality for the AbuseFilter/ConfirmEdit integration in these two patches:
suffusion_of_yellow
added a comment.
Edited
Jun 17 2024, 10:29 PM
2024-06-17 22:29:00 (UTC+0)
Comment Actions
I've reworked the functionality for the AbuseFilter/ConfirmEdit integration in these two patches:
Tried these patches. I am using the 2010 editor, and these options:
wfLoadExtensions( ['ConfirmEdit', 'ConfirmEdit/QuestyCaptcha'] );
$wgCaptchaQuestions = [
'What is the answer to Life, the Universe, and Everything?' => '42'
];
$wgConfirmEditEnabledAbuseFilterCustomActions = [ 'showcaptcha' ];

wfLoadExtension( 'AbuseFilter' );
First, I set a filter to "showcaptcha", and attempted an edit NOT adding external links. After clicking "publish" the first time, at the
top
of the page, I got the message "Incorrect or missing CAPTCHA." even though I was never asked for one in the first place. The actual CAPCTHA was at the
bottom
of the page. The page saved successfully when I answered correctly.
Second, I attempted an edit adding external links, keeping the filter set to "showcaptcha". This time, I got the standard "Your edit includes new external links..." message, and the captcha input was at the
top
, right below the message. (This is the expected behavior.)
Third, I set a filter to "warn" and "showcaptcha", and attempted an edit NOT adding external links. This time, I was bounced back and forth endlessly between the warning message and the request for a CAPTCHA. There was no way to save the page.
Fourth, I attempted an edit adding external links, keeping the filter set to "warn" and "showcaptcha". This time I got one request for a CAPTCHA, then the warning, then a second request, but the edit finally saved. (This is not optimal, but AFAIK an existing problem not caused by this patch.)
Thanks so much for testing and for the detailed notes!
So three improvements are needed here:
The message should say something other than "Incorrect or missing CAPTCHA." when no CAPTCHA was ever asked for.
I think this should be possible without too many hacks.
The CAPTCHA input should be at the top, near the message (same as when adding external links)
This one, I am not sure about yet. Maybe we could do that in a follow-up task?
There should be some way to save a page when a filter is set to warn+showcaptcha (other than adding a new link), or this option should be forbidden when saving a filter.
I would lean towards going with the latter ("forbidden when saving a filter") but I am not sure about how possible that is with AbuseFilter.
@Dreamy_Jazz
has +2'ed the patches and one of us will make follow up patches for these issues. The feature is behind a config flag so there is not a risk of this being in front of users.
gerritbot
added a comment.
Jun 27 2024, 4:55 PM
2024-06-27 16:55:01 (UTC+0)
Comment Actions
Change #1031886
merged
by jenkins-bot:
[mediawiki/extensions/AbuseFilter@master] ConfirmEditHandler: Use SimpleCaptcha API to invoke CAPTCHA display
gerritbot
added a comment.
Jun 27 2024, 4:55 PM
2024-06-27 16:55:03 (UTC+0)
Comment Actions
Change #1031885
merged
by jenkins-bot:
[mediawiki/extensions/ConfirmEdit@master] SimpleCaptcha: Allow invoking CAPTCHA display from other extensions
ReleaseTaggerBot
edited projects, added
MW-1.43-notes (1.43.0-wmf.12; 2024-07-02)
; removed
MW-1.43-notes (1.43.0-wmf.5; 2024-05-14)
Jun 27 2024, 5:00 PM
2024-06-27 17:00:35 (UTC+0)
Maintenance_bot
removed a project:
Patch-For-Review
Jun 27 2024, 5:30 PM
2024-06-27 17:30:40 (UTC+0)
sbassett
awarded a token.
Jun 27 2024, 6:28 PM
2024-06-27 18:28:33 (UTC+0)
suffusion_of_yellow
added a comment.
Jun 28 2024, 9:42 PM
2024-06-28 21:42:15 (UTC+0)
Comment Actions
I would lean towards going with the latter ("forbidden when saving a filter") but I am not sure about how possible that is with AbuseFilter.
FWIW, I tried setting one filter to "warn", and another to "showcaptcha", and it worked! I got both the warning and the CAPTCHA form on the same page, and after filling in the CAPTCHA, I was able to save the page. Not sure why it doesn't work when both settings are on the same filter; maybe it's just a minor bug?
kostajh
added a comment.
Jul 1 2024, 9:57 AM
2024-07-01 09:57:06 (UTC+0)
Comment Actions
In
T20110#9936300
@suffusion_of_yellow
wrote:
I would lean towards going with the latter ("forbidden when saving a filter") but I am not sure about how possible that is with AbuseFilter.
FWIW, I tried setting one filter to "warn", and another to "showcaptcha", and it worked! I got both the warning and the CAPTCHA form on the same page, and after filling in the CAPTCHA, I was able to save the page. Not sure why it doesn't work when both settings are on the same filter; maybe it's just a minor bug?
Ah, cool, good to know. Thanks.
kostajh
mentioned this in
T303433: Allow Stewards to enable 'emergency CAPTCHAs' for anonymous IP edits
Jul 2 2024, 10:33 AM
2024-07-02 10:33:46 (UTC+0)
gerritbot
added a comment.
Jul 9 2024, 7:57 AM
2024-07-09 07:57:31 (UTC+0)
Comment Actions
Change #1052909 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):
[mediawiki/extensions/ConfirmEdit@master] SimpleCaptcha: Show captcha-edit message if forceShowCaptcha is set
gerritbot
added a project:
Patch-For-Review
Jul 9 2024, 7:57 AM
2024-07-09 07:57:32 (UTC+0)
gerritbot
added a comment.
Jul 10 2024, 7:53 AM
2024-07-10 07:53:39 (UTC+0)
Comment Actions
Change #1053238 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):
[operations/mediawiki-config@master] ConfirmEdit: Enable showcaptcha action on testwiki and beta wikis
gerritbot
added a comment.
Jul 10 2024, 7:56 AM
2024-07-10 07:56:37 (UTC+0)
Comment Actions
Change #1053238
merged
by jenkins-bot:
[operations/mediawiki-config@master] ConfirmEdit: Enable showcaptcha action on testwiki and beta wikis
Stashbot
added a comment.
Jul 10 2024, 7:57 AM
2024-07-10 07:57:10 (UTC+0)
Comment Actions
Mentioned in SAL (#wikimedia-operations)
[2024-07-10T07:57:08Z] Started scap sync-world: Backport for [[gerrit:1053238|ConfirmEdit: Enable showcaptcha action on testwiki and beta wikis (
T20110
)]]
Stashbot
added a comment.
Jul 10 2024, 7:59 AM
2024-07-10 07:59:51 (UTC+0)
Comment Actions
Mentioned in SAL (#wikimedia-operations)
[2024-07-10T07:59:50Z] kharlan: Backport for [[gerrit:1053238|ConfirmEdit: Enable showcaptcha action on testwiki and beta wikis (
T20110
)]] synced to the testservers (
Stashbot
added a comment.
Jul 10 2024, 8:06 AM
2024-07-10 08:06:50 (UTC+0)
Comment Actions
Mentioned in SAL (#wikimedia-operations)
[2024-07-10T08:06:49Z] Finished scap: Backport for [[gerrit:1053238|ConfirmEdit: Enable showcaptcha action on testwiki and beta wikis (
T20110
)]] (duration: 09m 41s)
gerritbot
added a comment.
Jul 10 2024, 10:45 AM
2024-07-10 10:45:30 (UTC+0)
Comment Actions
Change #1052909
merged
by jenkins-bot:
[mediawiki/extensions/ConfirmEdit@master] SimpleCaptcha: Show captcha-edit message if forceShowCaptcha is set
kostajh
added a comment.
Jul 10 2024, 10:54 AM
2024-07-10 10:54:43 (UTC+0)
Comment Actions
In
T20110#9901516
@suffusion_of_yellow
wrote:
The message should say something other than "Incorrect or missing CAPTCHA." when no CAPTCHA was ever asked for.
That is done in
SimpleCaptcha: Show captcha-edit message if forceShowCaptcha is set
. Although, it's worth noting that VisualEditor and DiscussionTools do not update their CAPTCHA message on failure (not related to this implementation) as far as I can tell. But for source editor, you'll get an updated message after failing to submit an edit.
The
showcaptcha
AbuseFilter consequence is now available on testwiki and beta cluster wikis.
ReleaseTaggerBot
edited projects, added
MW-1.43-notes (1.43.0-wmf.14; 2024-07-16)
; removed
MW-1.43-notes (1.43.0-wmf.12; 2024-07-02)
Jul 10 2024, 11:00 AM
2024-07-10 11:00:34 (UTC+0)
Maintenance_bot
removed a project:
Patch-For-Review
Jul 10 2024, 11:30 AM
2024-07-10 11:30:47 (UTC+0)
Johannnes89
subscribed.
Jul 10 2024, 7:59 PM
2024-07-10 19:59:45 (UTC+0)
kostajh
mentioned this in
T357779: Provide ability to require temporary account users to complete a CAPTCHA in certain circumstances
Jul 12 2024, 6:35 PM
2024-07-12 18:35:12 (UTC+0)
kostajh
added a project:
Trust and Safety Product Sprint (Sprint Koto (July 15 - July 26))
Jul 23 2024, 12:19 PM
2024-07-23 12:19:46 (UTC+0)
kostajh
moved this task from
Priority Backlog
to
Needs QA
on the
Trust and Safety Product Sprint (Sprint Koto (July 15 - July 26))
board.
Edited
Jul 23 2024, 12:22 PM
2024-07-23 12:22:08 (UTC+0)
Comment Actions
For QA, it would be helpful to test out:
Adding a
showcaptcha
consequence
Triggering that consequence through API edits (VisualEditor, DiscussionTools) and non-API edits
The intention for this consequence is to be used in an editing context, but would be helpful to know how well it works / doesn't work in other situations (account creations, page moves, etc).
It could also be helpful to understand how the throttled notifications issue works out as discussed in
T303433#10017793
, but that could be QA'ed separately, if there isn't time to look at it here.
kostajh
updated the task description.
(Show Details)
Jul 23 2024, 12:22 PM
2024-07-23 12:22:59 (UTC+0)
gerritbot
added a comment.
Jul 23 2024, 12:25 PM
2024-07-23 12:25:49 (UTC+0)
Comment Actions
Change #1056146 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):
[operations/mediawiki-config@master] AbuseFilter: Enable showcaptcha consequence everywhere
gerritbot
added a project:
Patch-For-Review
Jul 23 2024, 12:25 PM
2024-07-23 12:25:50 (UTC+0)
XXBlackburnXx
subscribed.
Jul 28 2024, 5:19 PM
2024-07-28 17:19:36 (UTC+0)
Tchanders
edited projects, added
Trust and Safety Product Sprint (Sprint Erhu (August 5th - August 16th))
; removed
Trust and Safety Product Sprint (Sprint Koto (July 15 - July 26))
Aug 5 2024, 9:35 AM
2024-08-05 09:35:07 (UTC+0)
Tchanders
moved this task from
Priority Backlog
to
Needs Design Review
on the
Trust and Safety Product Sprint (Sprint Erhu (August 5th - August 16th))
board.
Tchanders
moved this task from
Needs Design Review
to
Needs QA
on the
Trust and Safety Product Sprint (Sprint Erhu (August 5th - August 16th))
board.
Aug 5 2024, 9:37 AM
2024-08-05 09:37:12 (UTC+0)
dom_walden
subscribed.
Edited
Aug 5 2024, 9:59 AM
2024-08-05 09:59:13 (UTC+0)
Comment Actions
In
T20110#10006557
@kostajh
wrote:
Triggering that consequence through API edits (VisualEditor, DiscussionTools) and non-API edits
I have seen the captcha for source editor, VE and DiscussionTools, and successfully edited after completing the captcha.
Editing via the API I get a response:
"edit": {
"captcha": {
"type": "image",
"mime": "image/png",
"id": "218847720",
"url": "/w/index.php?title=Spezial:Captcha/image&wpCaptchaId=218847720"
},
"result": "Failure"
The intention for this consequence is to be used in an editing context, but would be helpful to know how well it works / doesn't work in other situations (account creations, page moves, etc).
createaccount
Testing a filter with
action=="createaccount"
I could not get the captcha to work for the
createaccount
action on beta. Perhaps this is because IP and newly created users already see a captcha when trying to create an account.
Locally, I had to set
$wgCaptchaTriggers['createaccount'] = false;
in order to see the AF captcha consequence after trying to submit Special:CreateAccount. However, even after completing the captcha and re-submitting it does not succeed and continues to show the error
Incorrect or missing CAPTCHA
autocreateaccount
Filter with
action=="autocreateaccount"
Testing on dewiki beta, I do see the captcha after attempting to submit the edit. However, the temporary account has already been created at this point.
move
I could not get this to work for the move action. On beta, IP and newly created users cannot move articles. I had to test this locally and give all users move rights.
I did not test other actions like upload or delete.
Other observations
I could not get this to work for a global filter (testing on
). EDIT: I cannot get global filters to work at all, either on beta or locally.
gerritbot
added a comment.
Aug 7 2024, 11:37 AM
2024-08-07 11:37:25 (UTC+0)
Comment Actions
Change #1056146
merged
by jenkins-bot:
[operations/mediawiki-config@master] AbuseFilter: Enable showcaptcha consequence everywhere
XXBlackburnXx
added a comment.
Aug 7 2024, 1:30 PM
2024-08-07 13:30:23 (UTC+0)
Comment Actions
I created a global filter on Meta to test this:
it does seem to work, but I noticed one problem: whenever i tried to create an empty page (so no content at all), its keeps bouncing me back and forth to the warning that the page I will create is blank, and then to the captcha over and over again, without saving the edit.
codenamenoreste
subscribed.
Aug 7 2024, 7:54 PM
2024-08-07 19:54:50 (UTC+0)
Comment Actions
[see
for context] Under my alternative account, I've decided to test if it will show me the CAPTCHA, and it didn't; it just allowed me to create the page completely.
Also, it's worth noting that this action is NOT a restricted action per
on the edit filter noticeboard on enwiki.
Quiddity
moved this task from
Not ready to announce
to
In current Tech/News draft
on the
User-notice
board.
Aug 8 2024, 8:40 PM
2024-08-08 20:40:17 (UTC+0)
Quiddity
moved this task from
In current Tech/News draft
to
Already announced/Archive
on the
User-notice
board.
Aug 14 2024, 9:54 PM
2024-08-14 21:54:04 (UTC+0)
dom_walden
added a comment.
Aug 16 2024, 12:47 PM
2024-08-16 12:47:46 (UTC+0)
Comment Actions
In
T20110#10048229
@XXBlackburnXx
wrote:
I created a global filter on Meta to test this:
it does seem to work, but I noticed one problem: whenever i tried to create an empty page (so no content at all), its keeps bouncing me back and forth to the warning that the page I will create is blank, and then to the captcha over and over again, without saving the edit.
I can reproduce on VE. For Source Editor, I can only reproduce if I have a single AB rule which triggers both a warning and a captcha.
I wonder if it is the same bug as
T151116
@kostajh
In
T20110#10049437
@codenamenoreste
wrote:
[see
for context] Under my alternative account, I've decided to test if it will show me the CAPTCHA, and it didn't; it just allowed me to create the page completely.
@codenamenoreste
Does the user have the
skipcaptcha
right? This is assigned to autoconfirmed users, for example.
kostajh
mentioned this in
T372642: Create a "Challenge" type subtype of "Consequence"
Aug 16 2024, 1:31 PM
2024-08-16 13:31:34 (UTC+0)
JayCano
moved this task from
Sprint Erhu (August 5th - August 16th)
to
Sprint Theremin (Aug 26 - Sept. 6)
on the
Trust and Safety Product Sprint
board.
Aug 26 2024, 10:47 AM
2024-08-26 10:47:38 (UTC+0)
JayCano
edited projects, added
Trust and Safety Product Sprint (Sprint Theremin (Aug 26 - Sept. 6))
; removed
Trust and Safety Product Sprint (Sprint Erhu (August 5th - August 16th))
JayCano
moved this task from
Priority Backlog
to
Needs QA
on the
Trust and Safety Product Sprint (Sprint Theremin (Aug 26 - Sept. 6))
board.
dom_walden
moved this task from
Needs QA
to
Done
on the
Trust and Safety Product Sprint (Sprint Theremin (Aug 26 - Sept. 6))
board.
Aug 27 2024, 7:01 AM
2024-08-27 07:01:53 (UTC+0)
Comment Actions
In
T20110#10069310
@dom_walden
wrote:
In
T20110#10048229
@XXBlackburnXx
wrote:
I created a global filter on Meta to test this:
it does seem to work, but I noticed one problem: whenever i tried to create an empty page (so no content at all), its keeps bouncing me back and forth to the warning that the page I will create is blank, and then to the captcha over and over again, without saving the edit.
I can reproduce on VE. For Source Editor, I can only reproduce if I have a single AB rule which triggers both a warning and a captcha.
I wonder if it is the same bug as
T151116
@kostajh
I will do more testing of multiple/conflicting abuse filters when we implement
T372642
. I will move this along.
In
T20110#10049437
@codenamenoreste
wrote:
[see
for context] Under my alternative account, I've decided to test if it will show me the CAPTCHA, and it didn't; it just allowed me to create the page completely.
@codenamenoreste
Does the user have the
skipcaptcha
right? This is assigned to autoconfirmed users, for example.
I could have just checked this myself. The
user
is in the group "autoconfirmed users" which does have the
skipcaptcha
right
I assume that is the reason they did not see the captcha.
kostajh
mentioned this in
T373422: jQuery.Deferred exception: this.setSaveErrorMessage is not a function
Aug 27 2024, 9:52 AM
2024-08-27 09:52:04 (UTC+0)
kostajh
mentioned this in
T373797: Make it possible to silence "high rate of matches" AbuseFilter notifications
Sep 2 2024, 11:37 AM
2024-09-02 11:37:37 (UTC+0)
kostajh
closed this task as
Resolved
Sep 13 2024, 10:56 AM
2024-09-13 10:56:04 (UTC+0)
kostajh
updated the task description.
(Show Details)
Maintenance_bot
edited projects, added
User-notice-archive
; removed
User-notice
Sep 23 2024, 11:31 AM
2024-09-23 11:31:37 (UTC+0)
Maintenance_bot
removed a project:
Patch-For-Review
Sep 23 2024, 12:30 PM
2024-09-23 12:30:47 (UTC+0)
gerritbot
added a comment.
Dec 12 2024, 9:48 AM
2024-12-12 09:48:06 (UTC+0)
Comment Actions
Change #1102740 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):
[mediawiki/extensions/AbuseFilter@master] ConfirmEditHandler: Remove method_exists checks
gerritbot
added a project:
Patch-For-Review
Dec 12 2024, 9:48 AM
2024-12-12 09:48:06 (UTC+0)
gerritbot
added a comment.
Dec 12 2024, 10:38 AM
2024-12-12 10:38:42 (UTC+0)
Comment Actions
Change #1102740
merged
by jenkins-bot:
[mediawiki/extensions/AbuseFilter@master] ConfirmEditHandler: Remove method_exists checks
ReleaseTaggerBot
added a project:
MW-1.44-notes (1.44.0-wmf.8; 2024-12-17)
Dec 12 2024, 11:00 AM
2024-12-12 11:00:24 (UTC+0)
Maintenance_bot
removed a project:
Patch-For-Review
Dec 12 2024, 11:31 AM
2024-12-12 11:31:39 (UTC+0)
gerritbot
added a comment.
Dec 12 2024, 2:20 PM
2024-12-12 14:20:54 (UTC+0)
Comment Actions
Change #1102863 had a related patch set uploaded (by Reedy; author: Kosta Harlan):
[mediawiki/extensions/AbuseFilter@REL1_43] ConfirmEditHandler: Remove method_exists checks
gerritbot
added a project:
Patch-For-Review
Dec 12 2024, 2:20 PM
2024-12-12 14:20:55 (UTC+0)
gerritbot
added a comment.
Dec 12 2024, 3:22 PM
2024-12-12 15:22:15 (UTC+0)
Comment Actions
Change #1102863
merged
by jenkins-bot:
[mediawiki/extensions/AbuseFilter@REL1_43] ConfirmEditHandler: Remove method_exists checks
Maintenance_bot
removed a project:
Patch-For-Review
Dec 12 2024, 3:30 PM
2024-12-12 15:30:47 (UTC+0)
Log In to Comment
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct.
Wikimedia Foundation
Code of Conduct
Disclaimer
CC-BY-SA
GPL
Credits