Page MenuHomePhabricator

page_restrictions_edit empty in AbuseFilter when page protection is inherited from a cascade
Open, Stalled, Needs TriagePublic


page_restrictions_edit empty in AbuseFilter when page protection is inherited from a cascade

Just what it says on the tin. When an edit is made to a protected page, the AbuseFilter can normally hook on it with the 'page_restrictions_edit' variable. However, when the protection is inherited from 'cascading protection' it is not populated, preventing filter matches.

Example filter:
Example edit:

Identified by Espresso_Addict@enwiki

Event Timeline

Xaosflux created this task.Feb 22 2019, 2:41 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 22 2019, 2:41 PM
Xaosflux updated the task description. (Show Details)Feb 22 2019, 2:43 PM

AbuseFilter uses Title::getRestrictions for all *_restrictions_* variables, and it seems like the method doesn't handle cascading restrictions.

I'd like to see this information in AF variables, no opinion as to the best way to accomplish it (including if a different variable should be used). A related item may be for edits that are protected by other means as well (such as a namespace protection, or a page type protection).

@Xaosflux for sure this would be useful. As for how, we'll probably just have to add another call to a core method and merge the result. Or maybe getAllRestrictions + filtering would be enough. However, IMHO we cannot do it now: old AbuseLog entries (before rEABF42bd0d84f4244ca2304c6d161f71d90a6a53030c in 2013) are associated with a full AbuseFilterVariableHolder object serialized in the DB. Unfortunately, this object contains non-computed variables as well, which are computed on the fly whenever you examine that hit. If we change the method used to compute restrictions vars, then their content will also be changed for such entries.
The solution is T213006, which aims to remove non-computed variables, but until then we'd be forced to add extra code for back-compat, and I'd rather avoid it.