Users need to enable a preference before gaining access to the IPs
from `user_unnamed_ip`, a protected variable.
- Add a preference that the user can check to toggle their access
- Check for the preference and the view right for logs that reveal
protected variables on:
+ AbuseFilterViewExamine
+ SpecialAbuseLog
+ QueryAbuseLog
Bug: T371798
Change-Id: I5363380d999118982b216585ea73ee4274a6eac1
In my recent change c458651370, which used Status::getMessages()
in FilteredActionsHandler, I overlooked the fact that it returns
MessageSpecifier objects instead of Message objects, and the return
value of MessageSpecifier::getParams() is not exactly specified
(the docs only promise that it's an array).
Now I'm working on a MediaWiki core change (I625a48a6ec) that
causes a different MessageSpecifier to be used, which stores
parameters in a different format, and would break that code.
To avoid problems, ConsequencesExecutor now stores Message objects
in the Status, which guarantees that FilteredActionsHandler will
get the same objects back.
Change-Id: I2c1bc8dde9a078d03badecf6d89443b65eeb92c5
A filter using a protected variable can be loaded via filter id
using testing tools even though the user might not have the right
to view protected variables. This can potentially leak PII and as
such, testing tools should check for the right before allowing
protected filters to be seen.
- Unload a filter asap if it uses protected variables and the
requestor doesn't have viewing rights. This:
+ disallows loading of existing protected filters on page load
+ disallows testing against rules that use protected variables
+ disallows subsequent requests for protected filters (via API)
There is a known bug (see T369620) where no user feedback is
provided if an API request for a filter returns no result (typically
when no filter matches the requested id). This commit adds another
pathway to that bug (the filter exists but is protected and not
returned by the API) but does not update this UI/UX.
Bug: T364834
Change-Id: I6a572790edd743596d70c9c4a2ee52b4561e25f3
Why:
- Ie13181b78b8e2903c6cc0f0f778689bcc8b8ce2e modifies the status message
returned
What:
- Loosen the check for the status error message such that 'captcha-edit'
and 'captcha-edit-fail' are both valid; we can revert this after
Ie13181b78b8e2903c6cc0f0f778689bcc8b8ce2e is merged
Change-Id: I5a0698d84932a474800a68dba9b76b3433b19290
Why:
- These checks are no longer needed, now that Idc47bda has been merged
What:
- Remove the `method_exists()` checks
Change-Id: I6e428df6b6e036146ae4cc57374cde8810d3f5f7
Search is restricted to users with the right to view private variables
but not necessarily the right to view protected variables. Users who
don't have the right to view protected variables shouldn't be able to
search against protected variables, as this might leak the PII.
- Filter out filters using protected variables in search results
if the user doesn't have the right to view protected variables
Bug: T367390
Change-Id: I7412112c9cc676f29d706b116b779bc17183a952
Alternative approach to fixing the regression proposed by
Daimona in I78d3a2cd7bada962d7ef9b0f2c39d898bf8987ce.
Bug: T368203
Change-Id: I637367c3b3850f7988d890379fef7f4753159953
