Page MenuHomePhabricator

Reloading the page after reverting a file performs the revert again
Closed, ResolvedPublic


Steps to reproduce:

  1. Go to any file description page with more than 1 file in the file revision history.
  2. Hit the revert link on any file of the file history.
  3. Click on the confirm button to actually perform the revert.
  4. Hit F5 and accept the browser confirmation dialog (if any).


The revert is performed again whenever F5 is hit.

Expected results:

No more than a single revert should be done when reloading the page.

This may be done by doing a redirect to a different page once the revert is successful, like what is done after saving an edit or uploading a new file, so hitting F5 doesn't send the form again.

Another solution could be to check if the revert is going to upload the same file as the last version of the file. This would also help when people gets crazy when the cache isn't properly invalidated and start reverting the same file again and again... preventing this flood from happening.

Version: 1.22.0
Severity: enhancement

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:58 AM
bzimport set Reference to bz51383.
bzimport added a subscriber: Unknown Object (MLST).

Bryan.TongMinh wrote:

Well, that is the whole point of the browser confirmation dialog. In Firefox it states "[...]Firefox must send information that will repeat any action (such as a search or order confirmation) that was performed earlier". If you don't want to perform that action, click Cancel.

I suggest WONTFIX, since this is expected behavior.

While I agree that the browser issues a warning, this has been resolved for page editing where this doesn't happen.

Also, it can be used to perform a massive upload attack to quickly fill-up disk space and flood logs and recentchanges, by just reverting a huge file hitting F5 endlessly. And possibly resulting in a DOS.

Changing to enhancement for now, unless someone else thinks this may be a real issue.

I'm more concerned that this implies if two people revert a file at the same time, no conflict warning is issued. I think that's something that should be fixed

If people want to dos, fixing this wouldn't prevent them, it would just set the bar marginally higher.

Bryan.TongMinh wrote:

Good point. We could solve this by generating the edit token based on the timestamp of the file.

Change 308075 had a related patch set uploaded (by Bartosz Dziewoński):
RevertAction: Prevent file revert if current version is identical

Change 308075 merged by jenkins-bot:
RevertAction: Prevent file revert if current version is identical

matmarex claimed this task.
matmarex removed a project: Patch-For-Review.