2009/7/23 Aryeh Gregor <simetrical+wikil...@gmail.com>: > On Thu, Jul 23, 2009 at 2:05 AM, Brianna > Laugher<brianna.laug...@gmail.com> wrote: >> Eh? I do. Else why bother even having a write API? Why bother even >> having the login aspect to the API? > > The API allows you to edit if you know the password of the account > you're using. I can't see the value in creating some mechanism to > allow editing from an account with some special limited authorization > that's less than giving away the account password in practice.
The value is that you don't train your users that it's OK to give their password away to random 3rd parties. With OAuth, you could also request/authorise particular kinds of actions, rather than a carte-blanche (which is what handing over your password is). e.g. only edits, not deletes, protects or blocks (all of which are available in the API). In fact maybe Wiki*edia's OAuth implementation would specifically only allow edits, or non-admin actions, something like that. >> The OAuth provider typically has a page on the service (say en.wp) >> that lists all the third party apps you have granted authorisation to. >> This authorisation can be time-limited in itself, but if an app starts >> misbehaving (say, doing edits you didn't tell it to do), you can >> revoke its authorisation from the service directly (rather than having >> to change your password to stop it). > > That doesn't greatly reduce the level of trust you'd need to have in a > service to authorize it to edit under your name. Oh, great, if it > goes rogue it can get my account desysopped/blocked and seriously > confuse or annoy a large number of people who know me, but at least I > won't have to change my password! I imagine you could also have it so that actions made via the API identify where they are made from. (a la Twitter's "from web", "from twhirl" etc) In that case, if that information was exposed in the UI, it would be easy to identify rogue applications and block them completely across the site. In fact that would be far better than the case where you just hand over your password, and there is zero information about where that edit "really" came from. > Yeah, great, and let's also have users let Facebook edit arbitrary > pages with their account name so that they can keep their profile > synchronized across sites. This just strikes me as a horribly bad > idea. When a user makes an edit, you should know that *that user made > the edit*. Users should not be encouraged to let random third parties > use their account for any purpose. Well it sounds to me like you are opposed to the whole principle of having a write API. No? > So, my two cents: no. Any application that's useful can be integrated > into MediaWiki itself, or a toolserver tool, or a client-side program > with access to the password. Client-side as in a desktop application? How is that any different? Couldn't an evil desktop app send its passwords off to its evil author who then uses them for evil purposes? cheers, Brianna -- They've just been waiting in a mountain for the right moment: http://modernthings.org/ _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
