Last modified: 2013-07-08 17:21:27 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T34216, the corresponding Phabricator task for complete and up-to-date bug report information.
First Last Prev Next    This bug is not in your last search results.
Bug 32216 - AbuseFilter should use the APIEditBeforeSave hook
AbuseFilter should use the APIEditBeforeSave hook
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
AbuseFilter (Other open bugs)
unspecified
All All
: High enhancement (vote)
: ---
Assigned To: Chris Steipp
:
Depends on:
Blocks: noncoreapi 50472
  Show dependency tree / graph
 
Reported: 2011-11-05 15:04 UTC by Brad Jorsch
Modified: 2013-07-08 17:21 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Brad Jorsch 2011-11-05 15:04:16 UTC 
When an API edit is blocked by an AbuseFilter, the response received is particularly unhelpful:

    <?xml version="1.0"?><api><error code="hookaborted" info="The modification you tried to make was aborted by an extension hook" /></api>

No indication that it was even due to the abuse filter.

The abuse filter should be modified to use the APIEditBeforeSave to return appropriate information for API edits (see how SpamBlacklist does it, for example). This would probably also require adjusting EditPage to give access the edit summary stored in there.

Or I suppose EditPage could be modified to report the responsible extension whenever a hook aborts an edit, but that seems like it might be harder.
Comment 1 Sam Reed (reedy) 2011-11-05 15:35:43 UTC 
Is this any better in newer versions?

I know Roan did some refactoring to the status objects on the API edit stuff...

I can't say hwether it is, just be interesting to know if you'd tried it
Comment 2 Brad Jorsch 2011-11-05 15:44:18 UTC 
Just tried it on my local test wiki updated to r102103, same behavior.
Comment 3 Sam Reed (reedy) 2011-11-06 11:50:50 UTC 
(In reply to comment #2)
> Just tried it on my local test wiki updated to r102103, same behavior.

Cheers
Comment 4 James Forrester 2013-06-30 19:00:25 UTC 
This is blocking VisualEditor display a not-terrible message (bug 50472), so bumping priority.
Comment 5 Andre Klapper 2013-07-01 16:09:12 UTC 
(In reply to comment #4)
> This is blocking VisualEditor display a not-terrible message (bug 50472), so
> bumping priority.

James: Any proposals for an assignee?
Comment 6 James Forrester 2013-07-01 16:50:56 UTC 
Having spoken to Chris, he says he'll look at it.
Comment 7 Gerrit Notification Bot 2013-07-04 00:26:21 UTC 
Change 71945 had a related patch set uploaded by Hoo man:
Make use of the APIEditBeforeSave hook for nicer errors

https://gerrit.wikimedia.org/r/71945
Comment 8 Gerrit Notification Bot 2013-07-08 17:19:30 UTC 
Change 71945 merged by jenkins-bot:
Make use of the APIEditBeforeSave hook for nicer errors

https://gerrit.wikimedia.org/r/71945
Comment 9 Marius Hoch 2013-07-08 17:21:27 UTC 
Chris merged my patch.
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.

Navigation
Links