Page MenuHomePhabricator

File histories should be paged
Closed, ResolvedPublic

Description

I've tried to introduce paging for file histories in the API, but found that it's not implemented in the UI either (it should). This seems to be because the code in File.php is very pager-unfriendly: file histories are gotten by calling File::nextHistoryLine() repeatedly, and there is no way to specify an offset at which to start. If that is possible, paging can be implemented.

Notice: the reason I think paging should be implemented is that vandals could upload thousands of different versions of an image, flooding the image history in both the UI and the API and potentially mounting a DoS attack (hence the high severity). I've limited the API to 500 file revisions as a temporary measure, and I suggest someone do the same with the UI.


Version: 1.12.x
Severity: major

Details

Reference
bz12645

Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 10:02 PM
bzimport set Reference to bz12645.

News flash: I looked at the LocalFile::nextHistoryLine() and it turns out to do a DB query on every call. As that function is typically called in a loop, that means DB queries in loops (waits for Domas to kill someone).

Introduced new method in r29966

(In reply to comment #1)

News flash: I looked at the LocalFile::nextHistoryLine() and it turns out to do
a DB query on every call. As that function is typically called in a loop, that
means DB queries in loops (waits for Domas to kill someone).

ImagePage.php doesn't use that though. It does the old versions in one query and iterates using it's own wrapper so to speak. Does anything use nextHistoryLine() though?

Done in r44564 using getHistory()

Gilles raised the priority of this task from High to Unbreak Now!.Dec 4 2014, 10:21 AM
Gilles moved this task from Untriaged to Done on the Multimedia board.
Gilles lowered the priority of this task from Unbreak Now! to High.Dec 4 2014, 11:22 AM