Last modified: 2011-03-13 18:05:46 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 14356 - Moving user subpages is not rate limited
Moving user subpages is not rate limited
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.13.x
All All
: Lowest normal (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/w/index.php?t...
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-31 03:39 UTC by Nakon
Modified: 2011-03-13 18:05 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch to add rate limiting for moving/talk subpages (1.54 KB, patch)
2008-05-31 05:34 UTC, Alex Z.
Details
Alternate patch - move basepage last (7.46 KB, patch)
2008-05-31 21:15 UTC, Alex Z.
Details
Fix for previous patch (7.18 KB, patch)
2008-05-31 21:48 UTC, Alex Z.
Details

Description Nakon 2008-05-31 03:39:49 UTC
The option to "Move all subpages, if applicable" does not perform a rate-limiting check, which allows pagemove vandals to exploit this option and move all of a user's subpages.
Comment 1 Alex Z. 2008-05-31 05:34:53 UTC
Created attachment 4939 [details]
Patch to add rate limiting for moving/talk subpages

Adds a rate-limit-exceeded notice for each page that couldn't be moved in the list of pages that were supposed to be moved rather than $wgOut->rateLimited() so the user can still see the list of pages that were moved successfully (until they hit the limit) and which failed (due to the limit or other reasons).
Comment 2 Alex Z. 2008-05-31 21:15:58 UTC
Created attachment 4942 [details]
Alternate patch - move basepage last

Splarka on IRC suggested that if a rate limit is tripped, the base page shouldn't be moved so that remaining sub/talk pages can be moved using the "move subpages" and "move talk page" options on the base page. This patch changes the MovePage form submission to try to move subpages and talk pages first, if applicable, then the base page if no rate limits are tripped. I tested it in various situations:

1. Limit hit before all subpages can be moved:
* Subpages moved as long as the rate limiter allows
* Base page not moved

2. Rate limit hit before anything can be moved:
* Uses standard $wgOut->rateLimited();

3. No rate limits hit:
* Same action as it currently does

4. Subpages moved, rate limit hit when moving base page:
* Same as #1, but the base page is the only one not moved

**Note: For some reason, the subpages of user talk pages are moved into project-space. This doesn't happen with user pages, it seems to happen with the current code as well, might be related to bug 14258.
Comment 3 Alex Z. 2008-05-31 21:48:23 UTC
Created attachment 4943 [details]
Fix for previous patch

Fix docs on previous patch - "Alternate patch - move basepage last"
Comment 4 Brion Vibber 2008-06-02 16:00:57 UTC
This would just mean that there's no practical way to move pages with their subpages.
Comment 5 Mike.lifeguard 2008-06-02 16:20:35 UTC
If there is concern this will be abused, we could consider making the subpages-too option a sysop-only right.
Comment 6 Ilmari Karonen 2008-06-03 04:58:16 UTC
Hmm... how about queueing the subpage moves for delayed background execution using something like the job queue (though they should probably have their own separate queue) and (and this is the important bit) having the queue handler re-check that the user who initiated the move is still allowed to make it.  That would allow anti-vandal bots to interfere with massive subpage moves before they run to completion.  I know, probably not trivial to implement, but one can wish...
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-06-03 17:56:03 UTC
(In reply to comment #5)
> If there is concern this will be abused, we could consider making the
> subpages-too option a sysop-only right.

That might be a good idea, if only for the sake of the log spam.  Or at least make it autoconfirmed.  (It should be available to all users by default, though, since on a typical wiki there won't be enough pages with many subpages to make this harmful.)

(In reply to comment #6)
> Hmm... how about queueing the subpage moves for delayed background execution
> using something like the job queue (though they should probably have their own
> separate queue) and (and this is the important bit) having the queue handler
> re-check that the user who initiated the move is still allowed to make it. 
> That would allow anti-vandal bots to interfere with massive subpage moves
> before they run to completion.

Seems ineffective.  Besides, in the long run it may be more efficient to move all of the pages in a single query.
Comment 8 Charlotte Webb 2008-06-05 13:16:23 UTC
> > If there is concern this will be abused, we could consider making the
> > subpages-too option a sysop-only right.
> 
> That might be a good idea, if only for the sake of the log spam.  Or at least
> make it autoconfirmed.  (It should be available to all users by default,
> though, since on a typical wiki there won't be enough pages with many subpages
> to make this harmful.)

One must already "autoconfirmed" to move individual pages (at least on enwiki -- default settings are probably more lax) so this would have no effect on vandalism.

Log spam might be better avoided by collapsing a "page and sub-pages" move into a single log action (expandable for those who wish to see the whole list). A quid pro quo "(revert all)" link would ensure that bad multi-page moves are entirely corrected, as would a button to delete all the redirects in one fell swoop, though these ideas should probably go on a separate ticket.........
Comment 9 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-06-05 18:11:06 UTC
(In reply to comment #8)
> Log spam might be better avoided by collapsing a "page and sub-pages" move into
> a single log action (expandable for those who wish to see the whole list). A
> quid pro quo "(revert all)" link would ensure that bad multi-page moves are
> entirely corrected, as would a button to delete all the redirects in one fell
> swoop, though these ideas should probably go on a separate ticket.........

The log format is pretty inflexible at present, unfortunately, but what you say is probably the best interface, yes.  Another bug would be good.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links