Page MenuHomePhabricator

🥸 Wikibase REST API does not fully support temporary accounts
Closed, ResolvedPublic8 Estimated Story Points

Description

In order to enable browser-like clients interacting with Wikidata to register temporary accounts on WMF's central login wiki, responses to edits that resulted in using a "temporary account" should include the relevant data: name of the temporary account used, and the "redirect URL" that could be used to register the temporary account on the "central login wiki".

Successful edit responses (POST, PUT, PATCH, DELETE endpoints) should send the following HTTP headers if the edit involved creating a mediawiki temporary account:

  • X-Temporary-User-Created with a value being a temporary account user name
  • X-Temporary-User-Redirect, if a redirect URL value was generated by Mediawiki
  • the returnTo value expected by TempUserCreatedRedirect should be left empty for now (in production this will mean, redirected request will return to the Main Page)

At the same time, a temporary account should never be returned as the value of X-Authenticated-User (see T323261).

Description of the X-Temporary-User-Redirect header along the lines of: For the client that is a browser working with the WMF wikis: URL that client should redirect their user to ensure that the temporary account would be logged in on the central login wiki


While looking at the REST API code today, I noticed that it just throws away most of the information in the EditEntityStatus returned by EditEntity:

EntityUpdater::createOrUpdate()
		$status = $editEntity->attemptSave(
			$entity,
			$this->summaryFormatter->format( $editMetadata->getSummary() ),
			$newOrUpdateFlag | ( $editMetadata->isBot() ? EDIT_FORCE_BOT : 0 ),
			false,
			false,
			$editMetadata->getTags()
		);

		if ( !$status->isOK() ) {
			if ( $this->isPreventedEdit( $status ) ) {
				throw new EntityUpdatePrevented( (string)$status );
			}

			throw new EntityUpdateFailed( (string)$status );
		} elseif ( !$status->isGood() ) {
			$this->logger->warning( (string)$status );
		}

		return $status->getRevision();

The savedTempUser and context from the status are not used by the REST API, as far as I can tell. I assume this means that the REST API never calls the TempUserCreatedRedirect hook, and doesn’t redirect the user to loginwiki; consequently, a temporary user created via the REST API will only exist on the Wikibase repo wiki and be even more temporary than it should be.


Task breakdown

  • Add X-Temporary-User-Created and X-Temporary-User-Redirect headers to responses where the request came from a temp user
  • Remove X-Authenticated-User header from responses where the request came from an anonymous user

Event Timeline

I assume this means that the REST API […] doesn’t redirect the user to loginwiki

Hm, I hadn’t fully thought this through when I wrote that. Should the REST API return an HTTP-level redirect in its response, like I implied there? Or should it include a redirect URL in its response data, like the Action API does, potentially with additional API parameters like returnto, returntoquery and returntoanchor?

I assume this means that the REST API […] doesn’t redirect the user to loginwiki

Hm, I hadn’t fully thought this through when I wrote that. Should the REST API return an HTTP-level redirect in its response, like I implied there? Or should it include a redirect URL in its response data, like the Action API does, potentially with additional API parameters like returnto, returntoquery and returntoanchor?

I would recommend looking at what VisualEditor (T332435: Update VisualEditor for IP masking(and DiscussionTools do, both in terms of response data, and handling redirects.

I was trying to turn this rather low level technical description into a definition of an intended behaviour. Starting at Visual Editor tickets and patches didn't help me understand it loads, but I tried to follow some hints from @Lucas_Werkmeister_WMDE.

Excerpt from Action API response - I suspect the intended behaviour would be that REST API response also includes this information in some form

...
    "tempusercreated": "~2024-REDACTED",
    "tempuserredirect": "https://login.wikimedia.beta.wmflabs.org/wiki/Special:CentralLogin/start?token=REDACTED",
...

I am quite convinced that Wikibase REST API, unlike Action API, shouldn't be setting any cookies, neither respond with HTTP redirects.
I've failed to check what Mediawiki REST API does in similar cases -- putting page seems to have a hard requirement of providing a bearer token which would imply this is logged-in users only API?

Note:

  • the temporary user name should not be communicated through Wikibase REST API's X-Authenticated-User header (it is not as of Sep 17 2024) as it would be violating the design guideline of temporary accounts functionality: "Temporary accounts should feel ephemeral. People should not think they have an account when they do not"

Note, there is some internal discussion of this here.

Jakob_WMDE renamed this task from Wikibase REST API does not fully support temporary accounts to 🥸 Wikibase REST API does not fully support temporary accounts.Oct 2 2024, 9:57 AM