Page MenuHomePhabricator

Admins cannot view revision-deleted revisions
Closed, ResolvedPublic

Description

See https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Revision_deleted_history_of_article

PermaLink: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=861409505#Revision_deleted_history_of_article

rMW4835a75ec564: Use RevisionRenderer for rendering ParserOutput caused PoolWorkArticleView to start checking revdel where it was not checked previously, leading to the article not being displayed as it should be when an admin clicks the "view" link.

Possible fixes include setting $audience = RevisionRecord::RAW at line 158 (to match the previous behavior where a $content was passed) or having the caller pass a constructor parameter to explicitly bypass the audience check.

Event Timeline

Anomie created this task.Sep 26 2018, 8:23 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 26 2018, 8:23 PM
Xaosflux updated the task description. (Show Details)Sep 27 2018, 2:29 PM
Xaosflux added a subscriber: Xaosflux.
daniel added a comment.Oct 1 2018, 8:54 PM

Possible fixes include setting $audience = RevisionRecord::RAW at line 158 (to match the previous behavior where a $content was passed) or having the caller pass a constructor parameter to explicitly bypass the audience check.

I'm confused - if the user has the appropriate permissions, we should it be necessary to bypass the audience check? Am I missing something?

daniel triaged this task as High priority.Oct 1 2018, 8:54 PM
Anomie added a comment.Oct 1 2018, 8:55 PM

PoolWorkArticleView doesn't use per-user audience checks, it either does RAW or FOR_PUBLIC.

Tgr added a comment.Oct 1 2018, 9:28 PM

or having the caller pass a constructor parameter to explicitly bypass the audience check.

That would be nicer than using the content override option to signal whether an audience check should be done, which is the old behavior.

I'm a bit confused about pool counter key handling - audience does not seem to be factor in at all. Doesn't that mean that deleted content could be exposed to normal users if the timing is unfortunate enough so that one PoolWorkArticleView falls back to the result of another? Also, output for a non-private audience should not be written into parser cache but I don't see how that's guaranteed, either.

Tgr added a comment.Oct 1 2018, 10:57 PM

To answer my own question, fallback happens via looking up the other worker's result in the parser cache, so as long as the parser cache is used correctly, it's fine. And the parser cache is only used for current revisions and there the audience does not really matter. What's still confusing is that fallback()/getCachedWork() don't check the revision ID. I guess that's just a bug that has little impact because old revisions rarely get stampeded...

Change 463922 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/core@master] Add audience parameter to PoolWorkArticleView

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

Change 463922 merged by jenkins-bot:
[mediawiki/core@master] Add audience parameter to PoolWorkArticleView

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

Anomie closed this task as Resolved.Oct 2 2018, 3:42 PM
Anomie assigned this task to Tgr.

It looks like we got this fixed in time for 1.32.0-wmf.24. See https://www.mediawiki.org/wiki/MediaWiki_1.32/Roadmap for a schedule for deployment to Wikimedia wikis.

Thank you, looks good - tested on Group2 projects.

Daimona reopened this task as Open.Oct 14 2018, 5:13 PM

While the original fix works fine, the problem is not totallly gone: for diff views, the text page isn't shown, while it previously was (example). I guess this isn't intended behaviour.

@Daimona - worked for me (example here: https://test.wikipedia.org/w/index.php?title=T205578_example&oldid=362683&unhide=1 on testwiki) - goes right to the deleted text.

@Xaosflux Yes, because that's a single-revision view, but my comment was about diffs.

For me, it doesn't:


I forgot to change language to english before taking the screenshot, but I guess it's still clear.

This seems like it should be filed as a new task to me. As far as I can tell the diff issue doesn't seem to have been caused by the same change.

That's possible. I noticed them both at the same time, but tomorrow I'll do a git bisect to see if they share the same cause.

OK I'm following you now, you expect to see the before and after diff, plus the revision compiled text below. I don't see that either, but I can't recall if I used to see it in this view.

@Xaosflux indeed. I'm almost sure the content was shown, but anyway it doesn't make sense to show the header with the time without any content below.

Unless this is completely different from the issue I remember and I'm confused, this indeed used to show content - the wrong content. The page's current content, to be exact. And nobody apparently noticed for a decade or so :)

CCicalese_WMF lowered the priority of this task from High to Medium.Nov 5 2018, 3:41 PM
CCicalese_WMF removed a project: Patch-For-Review.
CCicalese_WMF closed this task as Resolved.Dec 18 2018, 3:46 PM

I guess it's not necessary to show the right content, but shouldn't at least the header be removed? I mean the "Revision as of 14:04, 29 July 2018" from the example above.

Tgr added a comment.Dec 19 2018, 4:50 PM

Probably best to file a separate task about that.