Page MenuHomePhabricator

Create OAuth REST API module in the extension
Open, Stalled, MediumPublic

Description

Description

The MediaWiki Interfaces team recently introduced a new pattern for defining self-contained REST API Modules within the MediaWiki REST framework for REST APIs. REST API modules represent collections of related endpoints, which can be independently managed from other REST API modules. They create controlled flexibility through federated ownership, while also ensuring that related capabilities are self-contained, can be independently versioned, and can share object definitions and the like. They are therefore particularly well-suited for extension REST API definitions, which are already self contained. Module adoption also allows for things like controlling how and where the API is published, in terms of the spec discovery endpoint and the REST Sandbox.

The OAuth REST API endpoints are well-suited to become an API Module, particularly as we look to make improvements to OAuth flows and may need to introduce new versions. Having a dedicated module will likely also help with discoverability of these endpoints, so that it is easier for developers to request and manage their tokens.

Conditions of acceptance

  • OAuth API module is created
  • A high(er) quality spec is generated for OAuth API:
    • See: https://www.mediawiki.org/wiki/Documentation/API_documentation/Reference
    • A high level module description is created, with a link to the OAuth extension documentation.
    • Endpoints all have short descriptions and summaries
    • Parameter descriptions are helpful to human readers
    • Schemas are defined, with useful descriptions for all properties
    • Examples are created where needed
  • OAuth API module is available in the REST Sandbox dropdown
  • OAuth endpoints are removed from the "flat" MediaWiki definition

Helpful documentation

NOTE: We do not yet expect full compliance with the "required" fields in the OAD style guide. These guidelines were created to support the related linter work, but are not yet enforced.

Implementation notes

  • The process for creating a module is fairly straightforward; we expect the hardest part to be coming up with appropriate descriptions within the schema and endpoint definitions. Based on other teams completing this work, the whole process to takes a day or two. MediaWiki Interfaces is also down to help as much as necessary!

Related Objects

Event Timeline

@JTweed-WMF & @OWresch-WMF -- are we still looking good to get this pulled in and completed before the end of the quarter? Let me know if y'all need anything from MediaWiki-API-Platform-Team in terms of support or guidance as you get started too!

Tgr removed Tgr as the assignee of this task.Sun, Jun 21, 9:22 PM
Tgr moved this task from In Progress to Blocked on the MediaWiki-Core-Platform-Team (Kanban) board.
Tgr subscribed.

OAuth 2 endpoints are in the form of /oauth2/authorize, /oauth2/access_token etc. The REST API module framework doesn't support these currently (AudienceDesignation::fromModuleId() requires an explicit version number). That will have to be fixed in core, if this task is to happen.

OAuth 2 endpoints are in the form of /oauth2/authorize, /oauth2/access_token etc. The REST API module framework doesn't support these currently (AudienceDesignation::fromModuleId() requires an explicit version number). That will have to be fixed in core, if this task is to happen.

Alternatively, we could create new endpoints and, over an appropriate time period, migrate callers to them. I recognize that, in the case of OAuth, that might be a significant time period.

New endpoints in a REST module could point to the same handlers as the existing endpoints, so from a caller's perspective the behavior is identical and only the paths change.

That would either be an infinite migration, or merely very long but requiring us to spend a lot of time on communicating, tracking and prodding. There are about 2000 registered OAuth 2 clients at the moment (not counting the owner-only ones which don't rely on these endpoints).

It would also mean we'd have to maintain two different API declaration / self-documentation mechanisms for the foreseeable future, deal with split metrics, ensure identical handling in Varnish, the API gateway and SessionManager which all require custom logic for OAuth 2 endpoints, and to be exposed to any accidental future discrepancies that might be introduced between the two Module implementations. It's not a good place to be, IMO.

We're already going to be dealing with complicated transitions for the "vNext" endpoints. I don't see that as prohibitive. Unversioned endpoints that don't follow the same conventions as our other endpoints isn't a good place to be either, and that's where we'll be in roughly a year (assuming timelines don't drift too far).

We might have the option, at some stage, of rerouting at the API Gateway level, much as we're doing with the RESTbase endpoints, to help with the long tail.

With all that said, I don't want to discount the complexity or length of this particular transition. Also, the OAuth extension presumably gets used by third party wikis and if we make changes, we'll want to be respectful of the effects on them.

Suggestion: leave his task Blocked for now, and consider it in the context of the larger "vNext" migrations.

I can see why it would be unpleasant to have most but not all APIs follow a pattern, but won't that be the case either way, whether we use ExtraRoutesModule or SpecBasedModule? Allowing spec-based modules with no version number in the path seems to me like an easy change that's easy to undo in the future (it could require extra confirmation in the form of a config var or extra spec field, like "use_deprecated_route_prefix": true, to make sure people only do it while understanding the reasons against it). Publishing a new set of OAuth endpoints is also easy, but hard to impossible to undo; so I think the reasonable thing to do is to delay it until we commit to a proper migration. (Which might or might not actually happen - OAuth has been unowned and mostly unmaintained for 8 out of 10 years of its existence, and the average team halflife at the Foundation isn't very large. We are just in the process of scrapping the API Portal, which was the previous idea of how to expose OAuth to developers. I don't want to be annoying but it's really my experience over the years that these trends come and go and you don't want to assume a refactoring will definitely finish just because it got started.)

To put it another way, right now the documentability and ease of navigation of the REST Sandbox is tied to the URL structure of the endpoint, which just seems like a bad idea to me. From a framework perspective, there might be third-party wikis using third-party REST extensions which do not want to do an endpoint migration soon but would be happy to benefit from the sandbox improvements.

That said if you strongly prefer to block this until an endpoint migration gets resourced, that's fine with me also, it just seems like a missed opportunity.

Change #1305438 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/OAuth@master] Add documentation messages for OAuth 2 APIs

https://gerrit.wikimedia.org/r/1305438

Change #1305439 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/OAuth@master] [WIP] Turn OAuth 2 APIs into a module

https://gerrit.wikimedia.org/r/1305439

Tgr changed the task status from Open to Stalled.Mon, Jun 29, 12:57 PM
Tgr claimed this task.