Brianna Laugher wrote: > 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.
No, you just train them that it is OK to give almost full access to their account to random 3rd parties. For a non-admin, the ability to edit pages is the most important right. With the ability to edit pages, the 3rd party would be able to do pretty much anything you would need the password to do, except change the password. >>> 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. The damage is still done. There might be hundreds of edits to clean up, accounts that need to be unblocked, emails wondering why dozens of high-profile articles are filled with shock porn, etc. Or they could use the accounts to make valid-looking, but incorrect edits. Since the accounts are of trusted users, people may not question it and days might go by before someone realizes. > 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. Or people could just do neither. >> 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? The write API has plenty of valid uses that don't require users to hand partial control of their account to 3rd parties. -- Alex (wikipedia:en:User:Mr.Z-man) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
