Core Platform Team/Initiatives/Authority

Authority

Product Owner:	Daniel Kinzler
Technical Contact:
Status:	In Progress
Initiative Vision:	Read Edit
Initiative Description:	Read Edit
Epics, User Stories, and Requirements:
Time and Resource Estimates:	Read Edit
Open Questions:
Documentation Links:	Read Edit

Initiative Vision

< Initiatives

Vision: The principal authorizing an action is clearly modeled and readily available in code. Developers can check user permissions in a concise and clear way. Permission checks or rate limits applied by application logic can easily be tested.				Theme: Code health (decoupling)
Stakeholdr(s): MediaWiki developers (core and extensions) will benefit from clearer, more testable code The security team should be consulted to make sure the design is conceptually sound. Quality + test engineering may be interested since we are making code more testable by removing the need for global state. The Performance team should be consulted to ensure the proposed implementation is sound.	Problem: We currently rely on PermissionManager to perform permission checks. PermissionManager currently relies on global state to access information required to determine whether an action should be allowed (such as the web request and user session). Having the caller pass in that information as a parameter is not feasible, since the caller can and should not know what information the permission check is based on. We are lacking a mechanism to inform asynchronous jobs about what authority they run under, beyond a user account. restrictions based on OAuth grants or IP address are not enforced in jobs. The User object in some situations mixes information from the current web request with information for other users. There currently is no component that encapsulates the information relevant to permission checks.		Solution: Introduce a concept called "Authority" that models a principal's authority to perform an action. It encapsulates logic for performing permission checks, combining information about the user account with information about the current request and session, accounting for things like blocked IPs, OAuth grants, and rate limits. Provide different implementations for use in different situations (e.g. for the current user's session, for an async job, for a maintenance script, for temporarily elevated permissions of automated operations, etc) Authority instances are provided to and associated with application code in the same way this code currently gets a User object. This makes migration straight forward without the need for big structural changes.	Aligned Goals: Improve code quality by reducing coupling Improve code health by improving testability Improve maintainability by modeling domain concepts clearly

Initiative Description

< Initiatives

Summary

Explore modelling of Authority for permission checks (phab:T231930)

Significance and Motivation

High level: Improve readability, testability, and reliability. Concretely: experiment to inform the RFC that defines a new first class entity.

Outcomes

An experimental definition of the Authority interface along with a first implementation exists. Existing code code has been extended to support the new mechanism, partially by duplicating existing functionality. Other code continues to use the old mechanism. After the experiment has been evaluated, we will schedule time to either undo the changes, or make them stable and permanent.

Baseline Metrics

None given

Target Metrics

REST endpoints have been ported to using the new mechanism. At the end of the experiment, we commit to evaluate the new concepts and mechanisms, and then either remove them again, or commit to making them available for use throughout the MediaWiki ecosystem.

Stakeholders

see vision table

Known Dependencies/Blockers

some overlap with phab:T208776 (PageIdentity)

Time and Resource Estimates

< Initiatives

Estimated Start Date

None given

Actual Start Date

None given

Estimated Completion Date

It should be understood that once the spike project is finished, and the experiment evaluated, we need to schedule time to either undo the changes we made, or to follow through with the RFC, and make the changes permanent and stable once it is approved.

Actual Completion Date

None given

Resource Estimates

Three engineers for two sprints, doing at least six hours of pair programming per week, in addition to async work.

Collaborators

None given

Documentation Links

< Initiatives

Phabricator

phab:T261963

Plans/RFCs

phab:T231930

Other Documents

None given

Subpages

Poll

Team members are invited to voice support or opposition, and give their reasoning.

Support Makes sense PPchelko (WMF) (talk) 13:35, 8 September 2020 (UTC)[reply]
Support This work will allow us to not only decouple a key piece of core code but to test our approach to decoupling, measuring the impact of the work as well as unlocking us to approach future changes to our permission model. WDoran (WMF)
Support Removing another component that relies on global state sounds like a big positive to me NNikkhoui (WMF)
Neutral Not enough knowledge of the subject area to vote with confidence APaskulin (WMF) (talk)
Support Improving code health by improving testability sounds good to me. AMooney (WMF)
Support This will make code more testable CAndrew (WMF) (talk) 20:13, 8 September 2020 (UTC)[reply]
Support This initiative will improve code health and demonstrate management's commitment to addressing this issue.NNzali (WMF)
Support This would be a very positive change. I note that this initiative is just for exploring the change. If it is successful, we should be prepared for an additional resource commitment to introduce the change and migrate existing code. BPirkle (WMF)
Support Improves code quality and testability. CCicalese (WMF) (talk) 19:41, 10 September 2020 (UTC)[reply]

Please use the polling templates, for example:

* {{support}} I like this example!  ~~~~
* {{weak oppose}} This is not a great example example... ~~~~