This is a side-effect of not having a centralised T84962: Authn and authz as a service upon which RESTBase can rely to answer questions such as Can user X do operation Y on title Z for wiki W?. The alternative is for RESTBase to re-implement all of the MW security checks, which we are not keen on doing. Hence RESTBase's limited permissiveness.

Currently, RESTBase throws a 403 whenever any of sha1hidden, commenthidden or texthidden is returned for a specific revision. Would checking explicitly only for sha1hidden or texthidden do the trick, @Krenair? AFAIK, that's the current MW way.

Doesn't the output include data such as user and summary? Those do need to be hidden when revdeleted.

In T113117#1660797, @Krenair wrote:

Doesn't the output include data such as user and summary? Those do need to be hidden when revdeleted.

Not sure I understand what you mean. I believe MW API's output does include that. However, the revision has been deleted, then RESTBase will throw a 403, so no data will be returned at all.

The way I see it, the stumbling stone here is the fact that RESTBase throws a 403 even for commenthidden, which it shouldn't.

The output includes comment and user information though. Instead of just refusing to show anything, you should be suppressing *only* the parts covered by the revision deletion flag.

In T113117#1661455, @Krenair wrote:

The output includes comment and user information though. Instead of just refusing to show anything, you should be suppressing *only* the parts covered by the revision deletion flag.

This is the correct functionality, in my opinion. Granular deletion/suppression is a core workflow.

Ok, here's what we are going to do. When we ask for revision info form the MW API, we'll check the following flags and do the following actions:

• sha1hidden, texthidden or suppressed: throw a 403
• commenthidden: remove the comment field from the API's response (but allow the client to obtain the revision's HTML)
• userhidden: remove the user's credential from the response only

So if you get commenthidden and suppressed (but not texthidden) you're going to throw a 403? How does that make sense?

As I understand from the docs, suppressed field's meaning is to hide the information even from sysops. As we can't distinguish reads from normal user and sysopt, we can simply ignore that flag.

Indeed, good point @Krenair. I must admit I got confused because I mixed up two different things - retrieving the revision info itself and retrieving the revision's text.

In T113117#1670554, @Pchelolo wrote:

As we can't distinguish reads from normal user and sysopt, we can simply ignore that flag.

Yup, that's the way to go, /me thinks. So we take into account the *hidden flags as explained in my earlier comment and ignore suppressed.

It looks like http://parsoid-lb.eqiad.wikimedia.org/mediawikiwiki/VisualEditor%2Fchangelog?oldid=1888915 does suppress the user information, although I don't recall Parsoid having specific handling for these cases.

@cscott, Parsoid uses a PHP API response for the metadata, which has hidden fields already blanked out for you.

@Pchelolo, @mobrovac: +1 from me on that plan as well. We might grow support for suppression later, but for now it shouldn't make a difference.

PR 354 for RESTBase fixing this issue has been merged. It will be deployed shortly.