Page MenuHomePhabricator

RESTBase should honor wiki-wide deletion/suppression of users
Closed, ResolvedPublic


We currently hook into MediaWiki to detect changes in visibility attributes for a revision, including whether the author's name should be visible. However, RESTBase is unaware of when a user is blocked/suppressed across the entire wiki, and continues to make this information available.

This issue has a lot of moving pieces, so I'm going to start laying them out, and creating subtasks as necessary:

Define event

T122077: Define schema for a User-block event

Produce events

T122079: Update EventBus extension to produce User-block events

Consume events, persist a suppression set

As events are produced, a consumer will be needed to update a set of hidden users. Lookups against this set must be fast (they will be in-lined with every request that exposes author information).


Suppress user information

RESTBase will need to be updated to utilize the suppression set, and filter out user information accordingly.

Related Objects

Event Timeline

Eevans raised the priority of this task from to Needs Triage.
Eevans updated the task description. (Show Details)
Eevans added a project: RESTBase.
Eevans added a subscriber: Eevans.
mobrovac set Security to None.

To summarize a discussion from IRC:

@GWicke has raised the possibility of an alternative approach, one where an API would allow querying the block list as stored in MediaWiki directly. As checks against this API would be highly sensitive to latency, implementing this in the action API might not be feasible (I'm given to understand that minimum request latency is on the order of 10s of milliseconds), and so an external service would need to be implemented (external to MediaWiki).

This has the advantage of being simple, avoids any replication of data, and should be quite performant, but requires that a service contact the MediaWiki database directly.

There is another related issue with Parsoid exposing revision user names in the HTML <head> section. I started a discussion about removing this information in T122390: Is RDFa metadata in Parsoid HTML head actually useful to you / no user name & edit comment suppression in Parsoid <head> metadata.

GWicke raised the priority of this task from Medium to High.Jan 12 2016, 9:18 PM
GWicke lowered the priority of this task from High to Medium.Jan 29 2016, 10:54 PM

FTR, we have updated RESTBase to always load revision metadata from the action API when processing public revision metadata requests. This means that RESTBase now respects user suppressions in all metadata end points it exposes, except for the metadata contained in Parsoid's HTML output.

Lowering priority, as the remaining issue is blocked on Parsoid removing that metadata from its output, as discussed in T122390.

With the recent Parsoid deploy, this is basically resolved by not exposing any stored user information, and thus respecting user deletions / suppressions.

The only exception is old Parsoid content still in storage, which still contains user information in its HTML <head>. We should add a transform to strip this information. The upcoming version change is a good opportunity to do so.

GWicke claimed this task.

Since the last Parsoid HTML version increment, old HTML is now gone from storage, and no user information is exposed any more. Resolving.