Page MenuHomePhabricator

Create CheckUser API Module for the REST APIs in the extension
Open, In Progress, MediumPublic5 Estimated Story Points

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.

The CheckUser REST API endpoints are particularly well-suited to become an API Module, because it is not available for all MediaWIki users and developers. By breaking out these endpoints into their own API module, we can present additional context to users to explain their restricted access. Additionally, creating an API module is a prerequisite for future changes to allow for more programmatically restricted API access via API audiences (WIP).

Conditions of acceptance

  • CheckUser API module is created
  • A high(er) quality spec is generated for CheckUser API:
    • See: https://www.mediawiki.org/wiki/Documentation/API_documentation/Reference
    • A high level module description is created, with a link to the CheckUser 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
  • CheckUser API module is included in the spec discovery list (for now; confirm this behavior with the PSI team)
  • CheckUser API module is NOT available in the REST Sandbox dropdown (module override required to keep it hidden)
  • CheckUser 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.

Event Timeline

Dreamy_Jazz closed this task as Declined.EditedMay 8 2026, 2:00 PM
Dreamy_Jazz subscribed.

We disabled the CheckUser API (i.e. action=checkuser) by default and for WMF wikis in T396010 due to security concerns and lack of usage, so don't think we (Product Safety and Integrity) should spend time on this. Boldy declining this task

Unless you mean the temporary account IP reveal endpoints? If so, these are internal anyway so ideally no documentation would exist for them to avoid implying they are stable to use

The only REST API endpoints in CheckUser are specifically only intended to be interacted with by frontend code that calls the API and if we could have we would mark them internal in any automatically generated documentation (like in the normal API). Therefore, creating the documentation is probably going to give the wrong idea that these API endpoints are stable and can be called by code outside CheckUser

Additionally most of these endpoints do very different things (IP reveal for temporary accounts, a card showing mostly public information about a user, allowing any user to send http-client-hints for the action they perform) so I don't think grouping these for documentation would make much sense (as they are for different users and do very different things)

This is explicitly for the REST endpoints, yes. Apologies that wasn't clear in the description -- this ticket was supposed to be more of a placeholder for now, and just realized that I did not call the REST framework as clearly as I could have.

Totally understand that these endpoints are for internal usage. That is basically the purpose of this ticket -- we are starting to break apart extension APIs so that we can have clearer indications of the levels of access, instead of presenting everything as a flat list with no indicators of such. For example, explicitly marking internal endpoints, and/or fully restricting the endpoint so that they can only be used by specific features. This is the first step towards that migration and the ability to apply additional access control.

Updating the docs gives us the opportunity to indicate they are internal in the first place. I also think that it is still worth documenting APIs for internal users, to a degree. That being said, we are totally open to being more lenient with the documentation completeness, because they're for internal users. However, the request to make a module still stands for other reasons, so that we can also do things like hiding the docs or making them an internal 'opt-in' instead of being displayed alongside our truly public endpoints, which is what gives the impression of stability and availability for developers who should perhaps not be using them.

which is what gives the impression of stability and availability for developers who should perhaps not be using them.

Yeah, we do not support any stability or intend for any developers to use them except through the JS code that we write, so I'd prefer that these just don't appear in the REST sandbox at all

Dreamy_Jazz renamed this task from Create CheckUser API Module to Create CheckUser API Module for the REST APIs in the extension.May 8 2026, 9:13 PM
Dreamy_Jazz updated the task description. (Show Details)

I've updated the title of this to make it clearer this is just for REST API modules. I also don't think Product Safety and Integrity would have any capacity in the short-term to help on this, though confirming with a PM would best if our input is needed

BPirkle triaged this task as Medium priority.May 8 2026, 10:03 PM
BPirkle moved this task from Incoming (Needs Triage) to Backlog on the MW-Interfaces-Team board.
  • No config changes meaning it won't be displayed on the REST Sandbox
  • Good for onboarding onto REST modules
  • We could get the Product Safety and Integrity to review the patch
  • Should we then remove it from the extension json so it does not appear anywhere?
  • We are just matching what we have right now
BPirkle set the point value for this task to 5.Tue, Jun 2, 2:47 PM
BPirkle subscribed.

Estimated synchronously during sprint planning.

One significant purpose of story points is to overload developers, so estimating a little high is safer in this case.

From the task description:

  • CheckUser API module is created
  • A high(er) quality spec is generated for CheckUser API:

After conversation with @KineticPelagic , we decided to do these as two separate gerrit patches, both under this task.

Change #1300204 had a related patch set uploaded (by KineticPelagic; author: KineticPelagic):

[mediawiki/extensions/CheckUser@master] REST: Migrate CheckUser REST endpoints to a REST API Module

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

Change #1300204 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] REST: Migrate CheckUser REST endpoints to a REST API Module

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

Change #1300279 had a related patch set uploaded (by KineticPelagic; author: KineticPelagic):

[mediawiki/extensions/CheckUser@master] REST: Document CheckUser REST API handlers and add module unit tests

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

Change https://gerrit.wikimedia.org/r/1300204 fulfills:

  • CheckUser API module is created
  • CheckUser API module is included in the spec discovery list (for now; confirm this behavior with the PSI team)
  • CheckUser API module is NOT available in the REST Sandbox dropdown (module override required to keep it hidden)
  • CheckUser endpoints are removed from the "flat" MediaWiki definition

Change https://gerrit.wikimedia.org/r/1300279 fulfills:

  • A high(er) quality spec is generated for CheckUser API:

From the task description:

  • CheckUser API module is created
  • A high(er) quality spec is generated for CheckUser API:

After conversation with @KineticPelagic , we decided to do these as two separate gerrit patches, both under this task.

Change #1301299 had a related patch set uploaded (by KineticPelagic; author: KineticPelagic):

[mediawiki/core@master] REST: Allow 'rest-param-example' in `RestStructureTest`

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

Change #1301332 had a related patch set uploaded (by KineticPelagic; author: KineticPelagic):

[mediawiki/extensions/CheckUser@master] REST: Address PSI comments on CheckUser module localisation

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

Change #1301332 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] REST: Address PSI comments on CheckUser module localisation

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

Change #1301299 merged by jenkins-bot:

[mediawiki/core@master] REST: Allow 'rest-param-example' in `RestStructureTest`

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