Hi5 Rest implementation, would like to contribute

[smart_zoosk]

Hi everyone,

Recently I replaced Zoosk.com's custom OpenSocial and OAuth
implementations with the osapi library. So far so good. Kudos for
making a sweet library, and thanks for making my life easier.

I went ahead and developed an osapi plugin for Hi5's unique OAuth and
REST implementations. I would like to contribute it back to the
library. Who can I chat with about that?

Their quirky OAuth scheme was easy; I implemented class
OAuthSignatureMethod_Hi5 which extends OAuthSignatureMethod_RSA_SHA1
and overloads the fetch_public_cert method. This always for their
makeRequest calls to be verified.

I also wrote an external rest library (ExtRestIO) which sits in the io
folder. It uses osapiCurlProvider and osapiStorage to send and cache
RPC calls that do not adhere to the OpenSocial spec. I then wrote
Hi5RestIO which extends ExtRestIO, adding public functions for:

authPlain - makes a rest call using email/pass and returns a
Hi5AuthToken object
setAccessToken - allows for setting a Hi5AuthToken
hasAccessToken - allows for checking whether the Hi5RestIO instance
has a token
sendEmail - sends user->user emails
sendNotification - sends user->user notifications

This code is shipping to production soon and will be beat on by >100M
pageviews.

[Chris Chabot]

Hey Smart,

Glad you found the library useful & awesome news to hear you want to contribute to it!

The code contribution process is documented at:
http://code.google.com/p/opensocial-php-client/wiki/BecomingAContributor

One question: I was living under the impression that Hi5 used plain-old-vanilla-oauth, what is different in their implementation that it warranted a custom Auth class?

I can't really comment on the implementation of Hi5's specific functionality without really seeing the code, there is a bit of myspace specific functionality in the current osapi lib that can serve as a practical example of how this has been dealt with so far, but again without knowing the details I don't know if creating new IO classes is the best approach or not, it's certainly a new way of extending the functionality though :)

    -- Chris

[Chris Chabot]

Hey smartj,

Thanks for sending the patch through! Having taken a quick glance at the patch I do still have a few concerns about the design choice to hang the custom code of the core classes; Unfortunately I'm all but underway to some developer conferences so don't have the time to do a deep dive into it right now.

However someone on the client-libraries list might, and if not I'll get on it mid next week.

   -- Chris

---------- Forwarded message ----------
From: smart_zoosk <sma...@gmail.com>
Date: Mon, Nov 2, 2009 at 9:00 PM
Subject: Re: Hi5 Rest implementation, would like to contribute
To: Chris Chabot <cha...@google.com>


Hi5 uses an RSA public key to sign messages sent to consumers, but you
never sign messages to send to them. Their OS 0.8 REST end-points are
not authorized.  Also, their non-OS rest end-points use a non-standard
3-legged auth, whereby you send username / password of a app user to
their plain/auth end-point in order to get a temporary access token.
This gives you access to messaging, etc.  It is a pretty whack auth
scheme because in practice, you use ANY user's email/pass and get
access to all the REST services.

Anyhow, I made a diff file so you can see the changes against v1.1.0:
http://dl.getdropbox.com/u/288065/osapi_diff.txt

There are also some bug fixes in there which may or may not be already
fixed in the most recent build. I need to catchup with the latest
build at some point.

Typical use example:

// build a external rest object (external meaning non-OpenSocial)
$hi5Rest = new Hi5RestIO($apiKey, null, $osapiStorage);
// build a hi5 provider object
$servProvider   = new osapiHi5Provider();
// get the auth token, which may be already cached by the
$osapiStorage
$hi5AuthToken   = $hi5Rest->authPlain($userEmail, $userPassword);
// check the type returned
if ($hi5AuthToken instanceof Hi5AuthToken) {
 // we have a successful hi5 auth token. Set rest access
 $hi5Rest->setAccessToken($hi5AuthToken);
}
// ...
// some various code here
// ...
// send a notificaiton
$hi5Rest->sendNotification($body, $userId);

[smart_zoosk]

Awesome, please let me know when you think when you have time to check
it out.

I tried to reuse as much code as possible, but I didn't see anything
that could easily accomplish external, non-opensocial REST calls. So,
I made a new class that simplifies non-OpenSocial rest calls using the
existing osapiCurl, osapiOAuth, and osapiStorage classes. It delegates
all its calls through them, so there aren't any new pieces other than
a new framework stub for non-opensocial REST.

I didn't know what else to do, but I look forward to your guidance.

-J