Page MenuHomePhabricator

Re-enable ORES data in action API
Closed, ResolvedPublic


Most of the ORES-related functionality in the action API was disabled in due to T157206. Given that that issue was caused by excessive requests from a single client, the client has been silent for a long time, and disabling the API doesn't really do anything to prevent abuse (the same requests could still be done directly to the ORES API), there is no reason to keep the API disabled.

Mitigation of similar events in the future is tracked in T148997 and T137962, but given that those need to be done in the ORES API, and the action API is just one possible way to call the ORES API, it doesn't really make sense to block reenabling on that.

(Some mitigation also happened in T157983.)

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Change 350756 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/ORES@master] Use $wgOresRevisionsPerBatch == 0 to disable on-demand score fetch

Change 349955 merged by jenkins-bot:
[mediawiki/extensions/ORES@master] Revert "Remove all (except meta) API funcationality hooks"

Change 350756 merged by jenkins-bot:
[mediawiki/extensions/ORES@master] Use $wgOresRevisionsPerBatch == 0 to disable on-demand score fetch

@Joe ORES functionality in api.php will be reenabled with the next train (which is a week from now). If there is trouble again, $wgOresRevisionsPerBatch can be set to 0, which will prevent api.php from making any user-triggered requests to the upstream ORES API (but otherwise it will remain working, and data for new edits will still be fetched).

When disabled that way, the ores field will be missing in the API response for all revisions which do not have locally cached data (ie. are not in recentchanges). Clients will have to be able to handle that so adding Developer-notice.

Halfak claimed this task.