Maniphest T120409

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

Assigned To

Authored By

	Eevans
	Dec 4 2015, 7:58 PM

Description

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).

See: https://en.wikipedia.org/wiki/Bloom_filter

Suppress user information

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

Related Objects
Search...

Status	Assigned	Task
		Restricted Task
Duplicate	None	T109331 Deleted files sometimes remain visible to non-privileged users if permanently linked
Duplicate	None	T133819 upload-lb.ulsfo.wikimedia.org still allow access to some deleted files
Duplicate	BBlack	T119038 Image cache issue when 'over-writing' an image on commons
Resolved	• ema	T133821 Make CDN purges reliable
Resolved	daniel	T102476 RFC: Requirements for change propagation
Resolved	• GWicke	T84923 Reliable publish / subscribe event bus
Resolved	Ottomata	T114443 EventBus MVP
Resolved	Eevans	T116786 Integrate eventbus-based event production into MediaWiki
Declined	• csteipp	T120133 security review of ramsey/uuid
Resolved	• csteipp	T120212 Security review of EventBus extension
Resolved	• GWicke	T120409 RESTBase should honor wiki-wide deletion/suppression of users
Resolved	ssastry	T125266 Remove user name and edit comment from html <head>

Event Timeline

Eevans created this task.Dec 4 2015, 7:58 PM

Eevans raised the priority of this task from to Needs Triage.

Eevans updated the task description. (Show Details)

Eevans added a project: RESTBase.

Eevans subscribed.

Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptDec 4 2015, 7:58 PM

Eevans mentioned this in T120212: Security review of EventBus extension.Dec 4 2015, 7:59 PM

• GWicke mentioned this in T106455: Add a first-class representation of pages (title-associated information) in restbase.Dec 4 2015, 8:00 PM

• mobrovac triaged this task as Medium priority.Dec 5 2015, 3:44 PM

• mobrovac added projects: RESTBase-release-1.0, Services.

• mobrovac set Security to None.

Eevans updated the task description. (Show Details)Dec 18 2015, 12:48 AM

Eevans updated the task description. (Show Details)Dec 18 2015, 1:07 AM

Eevans updated the task description. (Show Details)Dec 18 2015, 1:23 AM

Eevans updated the task description. (Show Details)Dec 18 2015, 1:29 AM

Eevans updated the task description. (Show Details)Dec 21 2015, 8:49 PM

Eevans added a project: Event-Platform.

Eevans updated the task description. (Show Details)Dec 21 2015, 9:03 PM

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.

• csteipp added a parent task: T120212: Security review of EventBus extension.Jan 12 2016, 9:06 PM

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

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.

• GWicke mentioned this in T125266: Remove user name and edit comment from html <head>.Jan 29 2016, 10:56 PM

• GWicke added a subtask: T125266: Remove user name and edit comment from html <head>.

• GWicke removed subtasks: T122079: Update EventBus extension to produce User-block events, T122077: Define schema for a User-block event.

Bianjiang subscribed.Feb 1 2016, 5:55 AM

• mobrovac mentioned this in T125840: restbase 40% slower than old action api.Feb 4 2016, 5:41 PM

ssastry closed subtask T125266: Remove user name and edit comment from html <head> as Resolved.Feb 22 2016, 10:11 PM

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 added a project: Services-next.Mar 1 2016, 9:41 PM

• GWicke created subtask T128525: Strip old metadata from old Parsoid content <head>: mw:TimeUuid, user, comment.Mar 1 2016, 10:40 PM

• GWicke removed a project: Services-next.