Archive of "OAuth"

Archive for the "OAuth" Category

Distributed Comment UI

Posted on

I’ve been thinking today about distributed commenting. Better known as @replies. This is the idea where the comment author can have the option to own their comments on a blog post by having them syndicated through a provider of their choosing. They may show up on the target site as well, but the comment author owns the permalink.

Of course, we’ve deployed the technology to solve this. Salmon. I haven’t quite got this blog enabled yet (any day now), but when I do you’ll be able to comment here from your own site or a StatusNet or RStatus instance. It’ll show up here, and I’ll be notified, but you own the permalink.

This was possible before Salmon, using Trackbacks, but Salmon is much more robust and delivers the full content of the comment to the target site so that it can be properly syndicated.

You may not want all your comments on other sites showing up in your “main stream”, depending on the services you use and how they’re configured. That’s fine. That’s a UI problem on your provider’s end, and there are many ways to solve it (allowing a post to be marked “do not publish to main stream” seems the easiest).

Now for the hard part: UI. You don’t want to flip over to another site or app to comment. So unless you’re using one of the super aggregators that does not yet exist with built-in Salmon magic, what do you do? The site author needs some way to let you comment with UI here, but authenticated as yourself and with content owned by your provider.

Thankfully, we have OAuth, AtomPub, and discovery protocols. They’re a bit of a mess (everything that evolves over time is), but it’s slowly stabalizing and I can already reccomend some best practices. Ask the user for their WebFinger ID (use a nicer way of asking, ofc 🙂 ) — this could be, or, for example. If WebFinger discovery fails and you can interpret the ID as a URL (you probably can), then hit that. If it succeeds, check for a type=”application/atomsvc+xml” link. That’s your AtomPub endpoint. OAuth does not yet have a WebFinger-compatible discovery mechanism, so attempt OAuth discovery on the URL you have, the AtomPub endpoint, and the rel= link in the WebFinger result.

You now have an AtomPub endpoint and an associated OAuth endpoint. Unfortunately you may need to be set up to do OAuth with this particular provider, so we may be stuck (though you can always try a blank consumer token/secret pair, since more and more sites are supporting that). If you can get authorization, then you’re done.

While this seems complicated on a technical level, the UI is all very simple. You ask them where they blog, they tell you, you find out if they are set up to handle this and if so, you send them through an OAuth loop. You store the OAuth result in a cookie (maybe only if they checked “remember me”) so that you don’t have to do it a lot. When they post a comment using your comment forms, instead of saving the data you send it off to their site via AtomPub with an in-reply-to value set as your post. Poof.

A Small Extension

Assuming you followed all that, there’s one more thing you might want to do. You as a publisher might want to host all your comment data on some other site (say, With the above setup you can (just set in-reply-to correctly and you can do anything), but what about users who don’t have their own blog/microblog somewhere? For these users it should be fairly simple to set up a dummy/anonymous Salmon service, that gives OAuth automatically to anyone who asks and then sends Salmon slaps of content it receives over AtomPub. An AtomPub-to-Salmon proxy, if you will. Users who comment and don’t have an ID just have their content pumped through there, and you don’t even have to host anything! Awesome!

AtomPub + OAuth for WordPress!

Posted on

After getting the answers I needed from the OAuth list, I decided to go back to hacking at getting OAuth to play nice with AtomPub on my host.  I am pleased to report that it now works!  It requires a two-line patch to WordPress (for my host anyway, YMMV), and I had to change the wp-oauth plugin a bit (lastest in SVN), but I have successfully posted to my test blog using a remote AtomPub script authenticated using OAuth.

See some example code.  The future is bright!

OAuth and XRDS-Simple in WordPress

Posted on

I’m publishing two plugins today.  The first is pretty simple in what it can do for users directly – the XRDS-Simple plugin allows users to delegate their OpenID to their WordPress blog – basically letting you log in on OpenID enabled sites using your blog address, but without needing to run your own provider.

On a far geekier level, the plugin allows other plugins to add XRDS-Simple services and other information (such as OAuth Discovery) using a progammatic API.  A brief example of this API is on the plugin’s page.

I am also releasing a more DiSo related plugin – WP-OAuth.  This plugin enables interacting with WordPress authentication using the open OAuth protocol.  This could be exciting if combined with AtomPub or another protocol / format supported by WordPress or another plugin.

OAuth Discovery

Posted on

Take 2! Now enhanced with XRDSs! Eran has blogged about the changes and the initial vendor support.  This plays right into my dream of infinite interop.  I’m quite happy about how small the spec is now that it just rides on XRDSs.  There’s some weirdness (need two XRDs, can have one XRDSs reference another).  Eran has explained his reasoning to me and it makes sense, but I’m still not convinced that it’s necessary.

Anyway, I should roll out a new XRDSs and OAuth DiSo plugin soon with support for draft 2.  And new examples.  There is an alternate PHP class that Eran says will be including support. I will probably use that when it comes out, but I’ll bootstrap with JanRain Yadis and the standard OAuth PHP class for now.