Summary
AbuseFilter has a protected protection level that enforces protected variables be only used in protected filters. This feature should be expanded to allow variables to have additional requirements for access, intended to be set by other extensions.
Background
- AbuseFilter protected variables were added to support the addition of the user_unnamed_ip variable.
- This variable needed to be not publicly viewable, be only accessible by those who have rights to reveal IP addresses, and also require users to have enabled a preference to view the data
- Since then we have had a need for other protected variables that do not need these same level of restrictions
- To allow for this, we need to split the restrictions for the user_unnamed_ip variable off
- These additional restrictions were very WMF specific, so it has been decided that CheckUser will enforce these restrictions using access for IP reveal and it's preference
- This work will be done separately as part of T387333: CheckUser should impose IP viewing restrictions on AbuseFilter's `unnamed_user_ip` protected variable, but we need to add the code to support this in this ticket
- Users who do not meet the additional restrictions for access on a variable should be unable to see the filter in which it is used or the associated logs. In a sense, it should appear as if the filter was "super-protected" by having the variable present.
- However, It should be possible to remove the variable from a filter to make it back to a normal protected variable state.
- Logs should remain in this "super protected" state forever if they are associated with a filter that used one of these variables
Technical notes
- It should be possible to implement per-variable restrictions, but we will need to consider potentially caching the return value of the access methods due to using a hook
Acceptance criteria
- AbuseFilter exposes a method to add additional restrictions onto protected variable viewing