Log In
Create Task
Maniphest T20110

Define AbuseFilter consequence to display a CAPTCHA
Closed, ResolvedPublicFeature
Actions

Assigned To
Beetstra
Daimona
DanielFriesen
View All 31 Subscribers
Tokens
"Like" token, awarded by sbassett."Love" token, awarded by Ladsgroup."Love" token, awarded by Daimona."Like" token, awarded by Luke081515."Like" token, awarded by Ricordisamoa."Like" token, awarded by Gryllida."Mountain of Wealth" token, awarded by jayvdb."Like" token, awarded by He7d3r.

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
SubjectRepoBranchLines +/-
ConfirmEditHandler: Remove method_exists checksoperations/mediawiki-configmaster+18 -1
SimpleCaptcha: Allow invoking CAPTCHA display from other extensionsmediawiki/extensions/AbuseFilterwmf/1.43.0-wmf.5+24 -5
CaptchaConsequence: Use SessionManager to communicate with AbuseFiltermediawiki/extensions/AbuseFiltermaster+65 -0
zuul: Update AbuseFilter/ConfirmEdit phan and test dependenciesintegration/config
suffusion_of_yellow added a comment.EditedMay 14 2024, 7:15 PM

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

gerritbot added a comment.May 14 2024, 7:46 PM

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

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
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.EditedMay 14 2024, 8:10 PM
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.EditedMay 14 2024, 8:23 PM
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.

suffusion_of_yellow added a comment.May 14 2024, 9:39 PM

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

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

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

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.

kostajh added a comment.May 15 2024, 9:17 AM
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

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

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

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

Change #1031757 merged by jenkins-bot:

[mediawiki/extensions/ConfirmEdit@master] AbuseFilterHooks: Provide feature flags for AF custom actions

gerritbot added a comment.May 15 2024, 8:59 PM

Change #1031921 merged by jenkins-bot:

[mediawiki/extensions/ConfirmEdit@wmf/1.43.0-wmf.5] AbuseFilterHooks: Provide feature flags for AF custom actions

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
Stashbot added a comment.May 15 2024, 9:16 PM

kostajh added a comment.Jun 6 2024, 2:07 PM
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: https://gerrit.wikimedia.org/r/c/1031885 https://gerrit.wikimedia.org/r/c/1031886

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

So three improvements are needed here:

  • The message should say something other than "Incorrect or missing CAPTCHA." when no CAPTCHA was ever asked for.
  • The CAPTCHA input should be at the top, near the message (same as when adding external links)
  • 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.
kostajh added a comment.Jun 26 2024, 9:37 AM
In T20110#9901516, @suffusion_of_yellow wrote:

I've reworked the functionality for the AbuseFilter/ConfirmEdit integration in these two patches: https://gerrit.wikimedia.org/r/c/1031886

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.

kostajh added a subscriber: Dreamy_Jazz.Jun 27 2024, 4:30 PM
In T20110#9925563, @kostajh wrote:
In T20110#9901516, @suffusion_of_yellow wrote:

I've reworked the functionality for the AbuseFilter/ConfirmEdit integration in these two patches: https://gerrit.wikimedia.org/r/c/1031886

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

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

Change #1031885 merged by jenkins-bot:

[mediawiki/extensions/ConfirmEdit@master] SimpleCaptcha: Allow invoking CAPTCHA display from other extensions

sbassett awarded a token.Jun 27 2024, 6:28 PM
suffusion_of_yellow added a comment.Jun 28 2024, 9:42 PM

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

gerritbot added a comment.Jul 9 2024, 7:57 AM

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 comment.Jul 10 2024, 7:53 AM

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

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:59 AM

Mentioned in SAL (#wikimedia-operations) [2024-07-10T08:06:49Z] <kharlan@deploy1002> 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

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

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
kostajh moved this task from Priority Backlog to Needs QA on the Trust and Safety Product Sprint (Sprint Koto (July 15 - July 26)) board.EditedJul 23 2024, 12:22 PM

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.

gerritbot added a comment.Jul 23 2024, 12:25 PM

Change #1056146 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[operations/mediawiki-config@master] AbuseFilter: Enable showcaptcha consequence everywhere

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
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.
dom_walden subscribed.EditedAug 5 2024, 9:59 AM
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

gerritbot added a comment.Aug 7 2024, 11:37 AM

Change #1056146 merged by jenkins-bot:

[operations/mediawiki-config@master] AbuseFilter: Enable showcaptcha consequence everywhere

codenamenoreste subscribed.Aug 7 2024, 7:54 PM

[see https://meta.wikimedia.org/wiki/Special:AbuseLog/2803401 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

dom_walden added a comment.Aug 16 2024, 12:47 PM
In T20110#10048229, @XXBlackburnXx wrote:

I created a global filter on Meta to test this: https://meta.wikimedia.org/wiki/Special:AbuseFilter/361 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 https://meta.wikimedia.org/wiki/Special:AbuseLog/2803401 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.

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
In T20110#10069310, @dom_walden wrote:
In T20110#10048229, @XXBlackburnXx wrote:

I created a global filter on Meta to test this: https://meta.wikimedia.org/wiki/Special:AbuseFilter/361 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 https://meta.wikimedia.org/wiki/Special:AbuseLog/2803401 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 right.

I assume that is the reason they did not see the captcha.

Maintenance_bot edited projects, added User-notice-archive; removed User-notice.Sep 23 2024, 11:31 AM
gerritbot added a comment.Dec 12 2024, 9:48 AM

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 comment.Dec 12 2024, 10:38 AM

Change #1102740 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@master] ConfirmEditHandler: Remove method_exists checks

gerritbot added a comment.Dec 12 2024, 2:20 PM

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 comment.Dec 12 2024, 3:22 PM

Change #1102863 merged by jenkins-bot:

[mediawiki/extensions/AbuseFilter@REL1_43] ConfirmEditHandler: Remove method_exists checks

Code of Conduct · GPL ·

Follow Lee on X/Twitter - Father, Husband, Serial builder creating AI, crypto, games & web tools. We are friends :) AI Will Come To Life!

Check out: eBank.nz (Art Generator) | Netwrck.com (AI Tools) | Text-Generator.io (AI API) | BitBank.nz (Crypto AI) | ReadingTime (Kids Reading) | RewordGame | BigMultiplayerChess | WebFiddle | How.nz | Helix AI Assistant