Quite a while ago (like, in at least 2009), I started thinking about regaining control of all the content I was producing online. I was posting photos to Flickr, saving bookmarks to Delicious. I started Tweeting. I was checking in. All fun and games, and all of those services offer great tools for interacting with them (let’s face it, tools that are much better than WordPress’, because they are focussed on one thing). So I figured, why not write importers for these services and pull my content back over to my WordPress. And keep doing it periodically, so that I could keep using those tools. I want WordPress to be my “home on the web”, my digital hub, but I want to use these neat tools with their fancy apps and what-have-you.

Very quickly, I realized that if I was going to do anything useful on most web services, I’d need to be able to authenticate with them. No biggie, right? I know my username and password… Oh. Right. OAuth. Turns out that most web services use OAuth (or something similar) to authenticate, and it turns out that that’s actually a bit of a bear to implement, when all you want to do is write a simple little Twitter importer. And then again for a Foursquare importer. And a Flickr importer.

What I needed was a shared, generic authentication framework that would do all the heavy lifting for me. I would tell it I wanted a connection to specific service, and if it didn’t have one, it’d walk the user through the process of getting one. It’d give me a standardized format of authentication credentials and abstract out all the complexity of making authenticated requests against those services. Then it would make me a coffee*. What I needed, was Keyring.

And so Keyring was born. Basically it’s a bunch of code that’ll handle external authentication with a web service so you don’t have to. It’ll store tokens/passwords/whatever, can talk to all kinds of different services, and is really, really extendable. It also has hooks. Lots of them. So if you want to do something custom, you probably can. It’s intended to be a foundation for writing other plugins, and really doesn’t do much interesting on its own.

I already have importers written for Twitter, Delicious and Foursquare which are based on Keyring and so far they’re working pretty nicely. There’s a lot of work to go on this project though. For Keyring to be a truly powerful framework, I need to:

• Drastically improve the UI, which is a hodge-podge of hideousness at the moment
• Improve a few parts of the Core UX which are pretty clunky right now
• Put in some more failsafes/helpers for making sure things are up and running before allowing plugins to use Keyring
• Improve internal security
• Tighten up Permissions/Roles restrictions all over the place
• Handle multi-user blogs (especially around token storage)
• Work on Multi-Site
• Support more services (preferences? suggestions?)
• Figure out a good way of allowing people to drop in their own Service extensions (and not overwrite them with updates)
• Improve the handling of auth flows in other plugins, and preferably move as much of that logic as possible into Keyring Core

I’m slowly working on this, but it’s all kind of a personal project at this point, so it’s just a few hours here and there. My main goal is to get it functioning so that I can get my content back. Once that’s done, then I’ll spend more time tightening it up for other/platform use. I also have a couple of other “companion plugins” that I’m working on — auto-linking text for Twitter @mentions and #hashtags, mining posts and downloading remote media (e.g. Instagram images) and some stuff around geo for mapping things like Tweets and Foursquare checkins (all the geo-data is imported in the importers I wrote).

Next on the list is abstracting and then releasing the importers that I have. That will give people something more tangible to use as an example. After that I’ll be working on a Flickr importer, but that’s a pretty big project in and of itself.

So, what do you think? Useful? Waste of time? Massive, gaping, horrendous holes? LMK (in the comments) and we’ll see what we can do.

And you know the drill — patches welcome

* Sadly, Keyring will not make you coffee. Yet.

Interesting stats:

• 21 web services analyzed
• 10 (48%) are using OAuth (including YouTube)
• 5 (24%) are using AuthSub (also including YouTube)
• Dopplr is the only non-Google property using AuthSub
• Tumblr is the only property using plaintext passwords, although Posterous is using HTTP Basic, which is basically plaintext

Looks like OAuth is gaining some real traction, and in fact if Google switched over to using it, it’d have a real hold on the authentication space. That would probably be a good thing. Next up in my adventure will be seeing how truly conformant/compatible all these OAuth implementations are, and how portable my code be able to be in accessing them all.

If you’d like to add any others that you know about, please throw them in the comments and I’ll add them to the table above so everyone can find them.

With the new integrated authentication, when you hit webpad you are presented with a log in screen, where you enter a username/password as normal, then continue to the actual application.

I’m also currently looking at templating (thanks to a previous hack that Brad Choate made to webpad 2.0 which allowed it to selectively edit the contents of a file, only within certain regions (denoted by webpad tags of some sort). I will have this functionality included in the official release of webpad 3.0 Personal Edition, and it will definitely be a part of the Professional release.

Things may have been quiet, but they’re not completely dead!

As Robert discovered in this post, the server that responds to API requests moved from plant.blogger.com to www.blogger.com, so basically I was posting authentication requests to a server that didn’t exist. This has been rectified now and it appears to be operating properly.

Enjoy your blogging folks

To get around this, you can easily configure your AvantBlog channel to pass your username and password along with each request for the channel, as per these instructions;

1. Go to https://my.avantgo.com/home/ and log in using your *AvantGo* details
2. Click the “My Device” tab on the left
3. Click your “AvantBlog” channel to modify its settings
4. In the “Location” box, add the following onto the end of the address “?username=USER&password=PASS” (no quotes), where USER is replaced with your Blogger.com username, and PASS is replaced with your Blogger.com password.
5. Save the details (“Save Channel”) and exit AvantGo’s website
6. Synch your handheld again – you should find that you are now automatically logged into AvantBlog, and this should continue each time you synch, whether you post or not!

I’ll also post my warning that went with the mailing list email I sent out here;

Obviously, this method means that your channel is defined using your actual Blogger.com username and password, in plain text. These details are passed ‘over-the-wire’ in plain txt, so this is not particularly secure. The chances of someone exploiting this are minimal, however if your blog contains any sensitive information or is of a secure nature of any sort, I do not recommend that you configure AvantBlog using this method.

Enjoy!