useragent-clienthints API does not work on the SUL3 authentication domain
Closed, ResolvedPublicBUG REPORT
Actions

Description

When I set up a local wiki with CentralAuth and CheckUser enabled, and $wgCheckUserLogLogins = true, and a crude approximation of the shared authentication domain, I get

POST https://login.wiki.local.wmftest.net:11048/w/rest.php/checkuser/v0/useragent-clienthints/privatelog/57 500 (Internal Server Error)

This is expected inasmuch as we are intentionally disabling non-authentication-related APIs on the shared domain, but this is sort of authentication related. We should either enable it (that would require adding a new hook to the REST API), or stop CheckUser from making this request (by overriding mw.config.get( 'wgCheckUserClientHintsPrivateEventId' )).

Details

Related Changes in Gerrit:

	Subject	Repo	Branch	Lines +/-
	Filter REST API endpoints rather than using a blanket ban	mediawiki/extensions/CentralAuth	master	+46 -3

Customize query in gerrit

Related Objects
Search...

Status	Subtype	Assigned	Task
Resolved		Tgr	T384007 SUL3 Phase 1: All new account creation on group 0 and group 1 wikis
Resolved	BUG REPORT	Tgr	T381223 useragent-clienthints API does not work on the SUL3 authentication domain
Resolved		Tgr	T383011 Create an equivalent of ApiCheckCanExecute for the REST API

Event Timeline

Tgr created this task.Dec 1 2024, 4:16 PM

Restricted Application added a project: MediaWiki-Platform-Team. · View Herald TranscriptDec 1 2024, 4:16 PM

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

We should either enable it (that would require adding a new hook to the REST API), or stop CheckUser from making this request (by overriding mw.config.get( 'wgCheckUserClientHintsPrivateEventId' )).

It depends on whether this shared authentication domain would ever have CheckUser checks performed. If checks are expected to be performed, for example such as those done currently on login.wikimedia.org by stewards, then we still need to collect this data.

Restricted Application added a project: Trust and Safety Product Team. · View Herald TranscriptJan 3 2025, 4:30 PM

The authentication domain should be acting like the origin wiki and storing the CU data on the origin wiki, i.e., if initiating a login on enwiki, the CU data for that login is stored in the enwiki database, not the authwiki database.

Only account creation CU data is in the loginwiki database, not login events.

In T381223#10429432, @Dreamy_Jazz wrote:

It depends on whether this shared authentication domain would ever have CheckUser checks performed.

From the perspective of stewards, the shared domain is not really a thing that exists. They perform the check on some wiki, to get information about actions that happened on that wiki. Some of those actions might have happened via the shared authentication domain; currently gathering client hints for those actions is broken.

Tgr mentioned this in T383011: Create an equivalent of ApiCheckCanExecute for the REST API.Jan 5 2025, 5:01 PM

Tgr added a subtask: T383011: Create an equivalent of ApiCheckCanExecute for the REST API.

JTweed-WMF moved this task from Inbox, needs triage to In progress (DO NOT USE) on the MediaWiki-Platform-Team board.Jan 6 2025, 4:14 PM

Tgr claimed this task.Jan 6 2025, 9:18 PM

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

[mediawiki/extensions/CentralAuth@master] Filter REST API endpoints rather than using a blanket ban

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

gerritbot added a project: Patch-For-Review.Jan 16 2025, 11:51 PM

Tgr added a parent task: T384007: SUL3 Phase 1: All new account creation on group 0 and group 1 wikis.Jan 20 2025, 2:35 PM

Change #1112112 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Filter REST API endpoints rather than using a blanket ban

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