[wp-xmlrpc] OAuth alternative
Allan Odgaard
m123ixd02 at sneakemail.com
Wed Jun 18 09:16:05 GMT 2008
I am repeating myself, but just to make it clear how I would prefer
this granular security to be handled:
If Bob wants Flickr to post to his blog, he logs into his WP
installation and on the user page there is a button called “Generate
API Access Key”.
By clicking the button, WordPress will respond with something like:
Username: Bob+0000001
Password: d41d8cd98f00b204e9800998ecf8427e
Bob can then enter this into Flickr, MarsEdit, Google Docs, Ecto, etc.
and for all practical purpose, this appears as just another user, but
WordPress will know that this user is a restricted Bob (so posts
coming in from Bob+0000001 are published as from Bob).
The benefit is that _everything_ will work with this system from day
one, because no change needs to be done to MarsEdit, Ecto, Flickr,
etc. and there is no need to phase out the existing authentication
system (as one of the letters in the OAuth thread suggested).
If it is a common task for users to provide web applications with an
API key, I can see justification for automating that, and OAuth is a
protocol for this. Though I don’t think it should be done by
introducing a completely new protocol for applications to authenticate
with the blog because then in a year we will have two authentication
schemes. One offers granular security, the other does not. Some third
party clients will support only one of these two systems, some both.
Some blogging systems will likewise only support one of the two. The
safest will be for everything to support both, so how exactly did this
help making things more secure? Rather, we just added unnecessary
extra complexity to the XML-RPC system, and thus an extra burden on
everyone writing an XML-RPC client or server implementation.
Keep it simple…
More information about the wp-xmlrpc
mailing list