Page MenuHomePhabricator

AbuseFilter should use the APIEditBeforeSave hook
Closed, ResolvedPublic

Description

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.


Version: unspecified
Severity: enhancement

Details

Reference
bz32216

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 12:02 AM
bzimport added a project: AbuseFilter.
bzimport set Reference to bz32216.

sam wrote:

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

Just tried it on my local test wiki updated to r102103, same behavior.

sam wrote:

(In reply to comment #2)

Just tried it on my local test wiki updated to r102103, same behavior.

Cheers

This is blocking VisualEditor display a not-terrible message (bug 50472), so bumping priority.

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

Having spoken to Chris, he says he'll look at it.

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

Change 71945 merged by jenkins-bot:
Make use of the APIEditBeforeSave hook for nicer errors

https://gerrit.wikimedia.org/r/71945