Last modified: 2011-05-15 09:55:54 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 17461 - Separate privileges for redirecting
Separate privileges for redirecting
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Page protection (Other open bugs)
unspecified
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-12 12:44 UTC by Le Chat
Modified: 2011-05-15 09:55 UTC (History)
5 users (show)

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


Attachments

Description Le Chat 2009-02-12 12:44:52 UTC
I note with pleasure that the long-standing category redirect problem is to be solved (bug 3311). But this may be exploited by miscreants, since category redirects are likely not to be picked up on watchlists, but will affect article pages. Projects should therefore be able to configure a namespace (such as Category:) so that creating or changing redirects in that namespace requires a higher level of privilege (admins only or whatever) than other edits.

Please close this if such functionality already exists; but if it doesn't, then it probably ought to be introduced at least when the category redirection goes live.
Comment 1 p858snake 2009-02-12 13:06:55 UTC
Since a redirect is just a peiece of article text it would be hard to add permissions to it and i don't think that its goes with our openess policies
>Output of MWBOT Bot
><mwbot> Wikis are designed for openness, to be readable and editable by all. If you want a forum, a blog, a web authoring toolkit or corporate content management system, perhaps >don't use wiki software. There is a nice overview of free tools available at <http://www.opensourcecms.com/> including the possibility to try each system. For ways to restrict access >in MediaWiki, see !access.
Comment 2 Le Chat 2009-02-12 13:50:56 UTC
This is actually *pro*-openness, since it would enable most edits in the namespace to still be permitted, while otherwise it might prove necessary to protect the whole namespace to close the vulnerability to redirect vandalism.
Comment 3 Philip Tzou 2009-02-15 17:59:48 UTC
When a category redirect was changed, the redirect target won't be changed automatically. So don't be worried. This just like when a template changed its category, the categories of articles which transcluded the template won't be changed automatically. People need to refresh those articles or wait for system refreshing.
Comment 4 Chad H. 2009-03-19 18:06:22 UTC
(In reply to comment #2)
> This is actually *pro*-openness, since it would enable most edits in the
> namespace to still be permitted, while otherwise it might prove necessary to
> protect the whole namespace to close the vulnerability to redirect vandalism.
> 

Stop exaggerating. Anytime you restrict an action to a subset of a group, it's being more restrictive, not open.

I can't see any huge purpose in this, nor do we have the right code in place to allow only editing certain text for certain groups (related bugs on this?)
Comment 5 ipatrol 2009-04-03 21:31:17 UTC
We do have the $wgProtectedNamespaces right, but I don't see a point. Most vandalism reversion is done to quickly for watchlists to be of use, most is reverted by bots and semi-automated programs. I really dobut the need to make a shell change for a piddly little possibility. If someone wants to troll the web looking for evidence the vandals have discovered this change, go ahead. Otherwise, suggestion WONTFIX.
Comment 6 Chad H. 2011-03-22 13:49:38 UTC
Should've WONTFIX'd this 2 years ago.

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


Navigation
Links