Brianna Laugher wrote:
2009/7/23 Aryeh Gregor
<Simetrical+wikilist(a)gmail.com>om>:
On Thu, Jul 23, 2009 at 2:05 AM, Brianna
Laugher<brianna.laugher(a)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)