On Tue, Jun 4, 2013 at 9:50 PM, Brad Jorsch <bjorsch(a)wikimedia.org> wrote:
No, it doesn't. You think we didn't discuss
this already?
I'm sure you did, but it's kind of useless if nobody provides an
explanation. Do you really expect me to just accept that "some WMF
engineers somewhere decided it was best"?
If you go by module, then you have problems where you need to grant
specific rights for using modules like
list=categorymembers and
prop=revisions, but you can't grant the ability to edit normal pages
without also granting the ability to edit your user CSS/JS, and (if
you're an admin) the MediaWiki namespace and so on.
So at least you're aware of the issues with the module system.
The situation with user rights isn't any better. Editing a page
requires 'edit' and 'writeapi' (and also 'read' unless you're
blindly
overwriting pages), and likely 'minoredit' and
'skipcaptcha' would
also be wanted, and maybe also 'createpage', 'createtalk',
'autoreview', 'autopatrol', 'autoconfirmed', and 'bot'.
And at the
same time, you can't avoid granting the permission to write to your
user CSS/JS.
There's a difference between the permissions interface in the actual API
and the permissions interface in the UI. A bot may ask for
"read|writeapi|edit|createpage|createtalk", but the UI will only show the
user "Create and edit pages", because all users can read so there's no
point in asking, writeapi is an implied permissions needed for edit, and
createpage and createtalk are two sides of the same coin. In other words,
the rationale should not be "we will confuse the user", because we decide
what to show the user. It's impossible to come up with a single interface
that will be perfect for both humans and bots.
So what reason is there to not use actual permissions other than that
reason?
The approach taken in my patch may not be perfect, but at least it's
possible to fix without screwing around with the
permissions structure
of the rest of MediaWiki.
Putting aside the entire organization of permissions, your patch has
AuthPlugin take ApiBase as a parameter, which I oppose for a completely
independent reason.
*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | tylerromeo(a)gmail.com