Premshree's (品速力) Personal Weblog

As you probably know we launched Browser-Based Authentication. What this means is that users can grant third-party web-based applications access to their Yahoo! data. (Actually, this could be used for non web-based apps too.) For a more detailed explanation, go here.

Anyway, I’ll explain how this works using the Ruby interface I just wrote and (sorta) tested:

• Registering your web application: First off, you need to register your web application. After registration you’ll get your appid and shared secret.
• Logging-in users:

  obj = YBBAuth.new(appid, secret)
  obj.get_auth_url('')

  Once you get the auth URL, direct the user there. Now the user is informed that your amazing web application is asking for permissions (read, write or both) and whether he wishes to grant permission, etc. Once the user grants permission, Yahoo! will redirect the user to your application (you would’ve submitted the URL when registering for an appid).
• Getting user credentials: When Yahoo! redirects the user, it adds a token parameter to the URL. You need to extract this token in order to get user credentials:

  obj.get_access_credentials(token)

• Making an authenticated request: Now you can make authenticated GET/POST requests:

  obj.ws_auth_get_request('http://photos.yahooapis.com/V3.0/listAlbums')

  The above snippet makes use of the Yahoo! Photos API.

» The Ruby wrapper

The interface isn’t complete or well-tested (I have a flight to catch in a few hours so I need to leave in a bit). I’ll work on it in a day or two.

OSCON was a lot of fun. My talk went pretty well. I think. Here’s the presentation, if you’re interested.

A lot of the sessions and tutorials were nice—I mostly attended a bunch of Perl talks. Among the keynotes, the best, in my opinion, was Kathy Sierra’s.

Oh, this picture that I took won a runner-up prize at the Third Annual OSCON Photo Contest. So I got a HP Photosmart R717. Just like that.

Also, during the OSCON week, we released an update of our Search Web Services SDK. Here’s the announcement. It now includes the Lua and Ruby bindings that I had worked on earlier.

I’ll write more about the stuff that happened during that week if/when I get time.

» Pictures from OSCON 2006

I came across this interesting article that talks about how Google Talk does authentication:

[...]

As has been discussed all over the internet, besides PLAIN auth, Google Talk also has it's proprietary mechanism, commonly known as X-GOOGLE-TOKEN:

<auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl"mechanism="X-GOOGLE-TOKEN">
AHRva2VubWVjaGFu ..snip snip.. JS2RSVzE1aXlvZEMtZmpTUWhYTGE0Zw==></auth>

Allow me to take a side path here for a moment. I personnally wondered about this one for quite a while, until recently a friend of mine invited me to test a new web 2.0 service. Sorry, I can't tell you which, it being in private beta and all, but they did one very cool thing: You could sign in to the service using your Google Mail account. Did they struck a deal? No, the solution was much simpler: they used XMPP Authentication. XMPP aka Jabber is the underlying protocol to Google Talk. It's completely open and well documented and has some neat features which unfortunately didn't make it into Google Talk itself yet.

This is basically the foundation of a Single Sign-On (SSO) solution by Google! Hmm, why does that sound familiar? What other IM service offered Single Sign-on with an IM login?

That's right, Microsoft's Passport. Hold on, Google Talk/XMPP isn't just a SSO service, it's one that _EVERYONE_ can easily implement on their site, without the need for licensing fees and all! All your clients need is a free Gmail account.

[...]

The article goes on to explain how you could go about generating a token to authenticate against Google. Nice. Nice not because you could do that. Nice because Google doesn’t have an explicitly mentioned auth API, and you could still use it for SSO.

Those who know about the way Flickr does authentication for its web services would realize that you could actually use that mechanism to implement SSO in your own application. It’s really simple: you ask the user’s Flickr user name, authenticate the application by asking the user to grant it rights, check for validity of tokens when you need to. That’s about it!

Most of the web services we have today provide us some data (most of the Yahoo! web services, for example). These web services are typically for consumption by third-party applications. Other web services (Flickr, for example) provide interfaces to push data into their servers. Still others ask you to provide some data and the web service offers you with something functional (Yahoo! Maps, for example).

If you were to categorize these web services, they’d probably fall under one of the following categories: 1) data (pull/push), 2) functional. Now, a web service that would let third-party applications be able to do SSO would probably be categorized under infrastructure. Ditto with del.icio.us [ref]—a tagging platform.

Of course, if an auth mechanism is actually intended to be used for SSO by third-party applications, there’ll probably be more that the web service would have to offer—ability to define profile objects, user registration, etc.

It’s interesting to imagine a world where we have all (or, rather, many) of these—data, infrastructure, some functionality—available. You need to actually concentrate on what you really want to do with your application, rather than bothering about fundamental needs.

Heh, REBOL is fun at times. Somebody asked me that question—“What about REBOL?”. Um, I don’t think I’m going to find time to write an API or anything. Basically I’m not in any mood to add parse handlers for the various search types.

Well, there you go, a Yahoo! Search Web Services demo for REBOL. That’s about REBOL.

( Code... )

The screenshot was generated using REBOL itself: save/png %screenshot.png to-image out