Last modified: 2014-07-17 22:39:23 UTC
https://www.mediawiki.org/wiki/Special:GlobalBlockList/37.59.32.148 did not stop https://www.mediawiki.org/wiki/Special:AbuseLog/44335 This might be because it's a global rangeblock rather than a single block, but I did place a local block for this IP as a result. Also, I'm not sure if even ordinary local blocks stop it (abuse filter obviously does), as we'll have to see if the local block stops it.
Flow calls Title::userCan (https://github.com/wikimedia/mediawiki-extensions-Flow/blob/42e8d57fe5ff07d8c26b9d7add5e8749aecdd328/includes/WorkflowLoader.php#L249), which GlobalBlocking hooks into. Maybe something is bypassing that check?
Same deal with https://www.mediawiki.org/wiki/Special:Contributions/94.23.251.211 and https://www.mediawiki.org/wiki/Special:Contributions/123.125.19.44 , the latter of which is a single global block, so it is not limited to just global rangeblocks.
Also https://www.mediawiki.org/wiki/Special:Contributions/37.187.0.0/16 I don't know why the check is failing, but chances are that these are being submitted through the API, in case that makes a difference.
This also doesn't look good. https://www.mediawiki.org/wiki/Special:Block/185.8.237.178 is a tor node, so it might not just be limited to global blocks.
https://www.mediawiki.org/wiki/Special:Block/172.245.142.156 is both!
If I understand the report, it's saying that AbuseFilter is blocking it, whereas you expect it to be blocked by Flow. Are there any edits that actually went all the way through when they were blocked at the edit-time? Otherwise, this could just be a hook registration order issue.
Edit permissions should be being checked before it runs through the AbuseFilter. If the user can't edit the page, it shouldn't be wasting time running through the AbuseFilter/SpamBlacklist/etc.
(In reply to Kunal Mehta (Legoktm) from comment #7) > Edit permissions should be being checked before it runs through the > AbuseFilter. If the user can't edit the page, it shouldn't be wasting time > running through the AbuseFilter/SpamBlacklist/etc. Yeah, I researched more closely after that, and they're different hooks anyway. AbuseFilter doesn't even use the getUserPermissionsErrorsExpensive/userCan hook
In core, EditPage->edit calls EditPage->getEditPermissionErrors That calls Title->getUserPermissionsErrors with the default expensive true, which triggers hook checks Later EditPage->edit calls EditPage->attemptSave(), which calls EditPage->internalAttemptSave(). That then calls EditPage->runPostMergeFilters which does the EditFilterMergedContent, etc checks. --- Erik noted that in Flow, it's done in a different order. Specifically, WorkflowLoader calls Block->onSubmit early, which in turn calls Block->validate, which eventually checks the spam filters. Then, only later does it check blocking and userCan.
Change 142170 had a related patch set uploaded by Mattflaschen: Remove explicit isBlocked(), change permission ordering to match core https://gerrit.wikimedia.org/r/142170
Change 142395 had a related patch set uploaded by EBernhardson: Remove explicit isBlocked(), change permission ordering to match core https://gerrit.wikimedia.org/r/142395
Change 142170 abandoned by EBernhardson: Remove explicit isBlocked(), change permission ordering to match core Reason: @matt I'll go ahead and take over this patch frontend-rewrite branch is closed, resubmitted against master as https://gerrit.wikimedia.org/r/142395 https://gerrit.wikimedia.org/r/142170
Change 142395 merged by jenkins-bot: Remove explicit isBlocked(), change permission ordering to match core https://gerrit.wikimedia.org/r/142395
