Talk:Core Platform Team/Initiatives/Authority

Extension devs

It seems as though for a first version we would want to not be disruptive of extension devs. Either we can target a first version that leads to changes in specific extensions managed by WMF or, likely better, we reserve that for a second phase.

Security

Part of the intention here is to protect developers from easily making mistakes related to permissions, we should include security team once we get to the design doc phase but I think they should be listed as a stakeholder

Performance

Should be included for the same reason as security team.

Quality and test engineering

Since this is aligned with code health objectives we should included Quality and Test as a stakeholder.

Thanks Will. You are right. I was mainly thinking of groups who will benefit from the new structure. And extension devs are of course on of the groups. I'll update the stakeholder list.

"The User object in some situations mixes information from the current web request with information for other users."

Can the User Object changes be separate from the creation of the Authority?

"Some parts of the code, in particular asynchronous jobs, currently have no good way to know what authority they run under, and MediaWiki currently has no concept to represent such an authority."

What is the integration here? What other systems would this impact? How would the information be made available? Are there additional benefits of this wiring?

Some changes to the User object are inevitable when introducing Authority. But the project is designed to postpone breaking changes, and we can mark any additions as internal or unstable, so we don't commit to keeping them stable.

Asynchronous "jobs" run in MediaWiki itself, so there are no other systems involved. MediaWiki is only a monolith when you look at it in a component diagram. If you look at a process/communication diagram, it's an event based architecture (and has been for many years).

Currently, a user may be prevented from editing because the user is blocked, or the IP they are coming in from is blocked. But once the edit is made and async jobs have been scheduled, these jobs are executed with the user's permissions, without IP based restrictions. The same applies to OAuth grants: the apply in the original request, but not in async jobs later.

With authority, we can just determine and serialize the list of permissions a job should have, based on the current request, when scheduling the job. This way the job will then execute with only the given permissions. With the Authority interface, this becomes really straight forward.

Note that this requires some changes to the Job system which wouldn't be included in the first iteration of this. But introducing Authority enables this kind of logic.

"Improve maintainability by modeling domain concepts clearly"

This is called out as an aligned goal but modeling isn't explicitly called out as part of the solution, it seems like a clear first phase or does this already exist?

"Improve code health by improving testability"

Does this also change code design and thus improve testability?

The "clear modeling" does not yet exist... it's implicit in "introduce the Authority interface". That basically is the modeling.

Testability is improved in two ways: by having a simpe interface to mock, and by avoiding global state.