Maugrim The Reaper's Blog - Zend Framework

Google roll out OAuth Authorisation to all Google Data APIs

nospam@example.com (Pádraic Brady) — Mon, 30 Jun 2008 21:24:43 +0000

Last Thursday I saw this turn up on the OAuth mailing list, so I've spent a few hours over the weekend adding the final features to the OAuth For PHP library (proposed both to the Zend Framework and PEAR) to ensure it works. Thanks go out to David Koblas for his unprompted assistance to go test the library and uncover the remaining issues!

The actual announcement went out on one of the Google Blogs: http://googledataapis.blogspot.com/2008/06/oauth-for-google-data-apis.html

I'm currently rolling these changes into a new OAuth 0.0.3 release for the PEAR proposal (an arduous task which involves opening the command line and running "phing convert-to-pear" on a subversion export of the ZF base code ). Once that hits the proposal I'll switch into voting mode and see what comments the always insightful PEAR developers drop on top of me. Of course this means the changes are already in the matching Zend Framework Proposal respository at http://svn.astrumfutura.org/zendframework/trunk along with examples of its usage with the Ma.gnolia API and the Google Data APIs waiting for its future Zend review.

The OAuth Consumer is now hitting the point where I'd rate it as beta. Most of the absolutely neccessary features are finished, and could likely only do with a touch of the refactoring brush. The last major feature is implementing a backend storage solution for OAuth tokens.

The Google Data API support comes with a few gotchas. Its documentation show a clear preference for using GET instead of POST, though the Google OAuth server does appear to natively support POST requests for everything with the exception that it has a small bug which interprets an empty POST request body as a sort of phantom empty parameter which messes up the validation of a Client's RSA-SHA1 signature. Other then that it's ready to go. Might be time to add comments to my code.... The bug has been reported but it's still preferable to stick with GET requests unless the Google OAuth documentation ever specifies it as an option.

If all goes well, the dual proposal process across PEAR and the Zend Framework should make for a another good OAuth library in PHP. Next up in the near future when an OAuth Server is also implemented will be adding support for some common OAuth Extensions - talk of these is already accelerating on the mailing lists as discussions turn to the next iteration of the OAuth Core Specification which has taken on the name OAuth Core 2008.1 (a sort of dual date + revision number system).

For those watching the PEAR proposal, I'll roll out OAuth 0.0.3 to the proposal during tomorrow. The last two have been unstable at best while on the drawing board so this near-stable one should be a stark contrast since it works without any hitches.

OAuth For PHP Status Update...

nospam@example.com (Pádraic Brady) — Wed, 25 Jun 2008 00:21:00 +0000

Edit: Firefox 3 appeared to have auto filled in a password option on this entry previously - my apologies and here's the full entry!

Earlier today I finished up work on the initial OAuth library. It has a few rough edges and missing features, but the bulk of the work for an OAuth Consumer is there. The rest is refactoring, feature iteration, and testing.

The new library is specifically targeted as a dual-proposal. It has been proposed to both PEAR and the Zend Framework. Rather than maintaining two distinct versions, or one distinct version with a heavy dose of abstraction, both are derived from the Zend Framework version. In essence, I develop primarily on the Zend Framework version, iterate patches onto a simple Phing task-chain, and out comes the PEAR version. This extends itself into the test suite too. This allows me to use the same base code, with changes appropriate to the underlying system (e.g. using PEAR HTTP_Request instead of ZF Zend_Http_Request).

The Zend Framework Proposal
The PEAR Proposal

Comments to both are more than welcome. For anyone wishing to ask questions outside of these proposal processes, I have also established a mailing list on Google Groups for the "OAuth For PHP" project: http://groups.google.com/group/oauth-for-php.

Over the weekend I posted a quick example of using the Zend_Oauth component to retrieve data from Ma.gnolia's API, a similar example using the PEAR code is available at PEAR OAuth Ma.gnolia Example. If nothing else it highlights what remains to be done. Don't get me wrong - you could almost use the current code, but there is a lot of support that can be added to make use easier.

So what is remaining?

The initial library remained tightly focused on implementing OAuth across HTTP POST. Obviously this means GET is left languishing by the wayside for now. One of the reasons was simply that a narrow focus also has the benefit of simplifying testing. And what works with POST URL query strings, should apply similarly to GET requests.

Secondly, there is absolutely no backend storage medium available as yet. In the examples, I temporarily stored all tokens to the Session. Ideally I will implement both a File and DB based storage backend this week.

Thirdly, the workflow of an actual Web Service API interaction is externalised. There is no way to get the OAuth library to handle requests to web services internally, using a specialised OAuth client, automatically making authorised POST/GET requests with the relevant data. Rather you can extract the OAuth authorisation parameters as a Header or Query String value for use in any HTTP client you wish (perhaps not perfectly ideal but the flexibility won't tie you to any particular client implementation either ).

Fourthly, support for RSA signing is omitted. Technically there is a problem supporting PHP's openssl extension on two fronts. The first is that PEAR's Crypt_RSA is a slower native implementation of RSA which doesn't optionally offload work on ext/openssl. The second is that ext/openssl itself is a tricky extension - it's API is badly documented (one of the worst), and it tends to have BC issues across different PHP versions.

Lastly, there is no OAuth Server just yet! A Server is next on my agenda though, so expect it to commence development almost immediately.

The end goal however, is substantially closer than it was last week! We have code, tests and a working example. The community feedback channel is now open.

Another OAuth Library Is Born

nospam@example.com (Pádraic Brady) — Sat, 21 Jun 2008 20:40:56 +0000

I've spent some time over the last week, and I have completed an initial pass at writing an OAuth Consumer in PHP5. I'm biased, but it's a nice chunk of code capable of fairly routine POST based OAuth requests using either an Authorized header, or a raw url encoded POST request body. My main remaining task is final cleanup, included refactoring, rolling my final set of acceptance tests into PHPUnit from SimpleTest, and adding support for HTTP GET, RSA, and a storage API so tokens can be saved in the background rather than outside the API.

I wrote up a quick example script using the current source code - bear in mind the final API will be tweaked but this is a close match for what I'd expect to become final (I'll await community feedback before finalising anything!).

You can grab the code, which is geared up for integration into the Zend Framework as a Zend_Oauth component, from my proposals repository at http://svn.astrumfutura.org/zendframework/trunk/ (proposed components are in /trunk/library/Proposed). I fully expect to refactor a similar core library specifically for use with PEAR in the very near future.

Onwards with the example! I'm using the Ma.gnolia bookmarking service's API (version 2) here. If you intend actually running the example, you will need to create a Ma.gnolia account and visit http://ma.gnolia.com/applications/new to register an application to get hold of an OAuth Consumer Key. Registering an application is a bit confusing - but basically create an imaginary one (e.g. "Super Duper OAuth Test Application". Since you'll be the only user for now, you can use it across any OAuth testing regardless of application name. In the code, replace CONSUMER_KEY and CONSUMER_KEY_SECRET strings with the real thing.

The example isn't explained here - if you're unfamiliar with OAuth I'll explain it better in the future when this is all closer to completion. For now refer to the OAuth Core 1.0 Specification (the starting sections are pretty good at explaining things). The amount of code is indicative of features being wrapped around the existing API as they are not yet integrated directly (e.g. using Sessions to store temporary tokens instead of an internally referenced database). Also note that the example creates a new Access Key every single request (generally the annoyance of authorising yourself every time doesn't exist in a completed solution ).

What does the example do? Simply checks how many bookmarks members of the OAuth Ma.gnolia Group have saved. Think it was 126 or so. The printed response is XML.

<?php
session_start();

require_once 'Zend/Oauth/Consumer.php';

$options = array(
'requestScheme' => Zend_Oauth::REQUEST_SCHEME_HEADER,
'version' => '1.0', // there is only a 1.0 version for now <img src="/templates/default/img/emoticons/wink.png" alt=";-)" style="display: inline; vertical-align: bottom;" class="emoticon" />
'signatureMethod' => 'HMAC-SHA1',
'localUrl' => 'http://path/to/this/file.php', // change to this file's local URL
'requestTokenUrl' => 'http://ma.gnolia.com/oauth/get_request_token',
'userAuthorisationUrl' => 'http://ma.gnolia.com/oauth/authorize',
'accessTokenUrl' => 'http://ma.gnolia.com/oauth/get_access_token',
);

// replace with your own real application consumer key and key secret!
$consumer = new Zend_Oauth_Consumer('CONSUMER_KEY', 'CONSUMER_KEY_SECRET', $options);

if (!isset($_SESSION['ACCESS_TOKEN'])) {
if (!empty($_GET)) {
$token = $consumer->getAccessToken($_GET, unserialize($_SESSION['REQUEST_TOKEN']));
$_SESSION['ACCESS_TOKEN'] = serialize($token);
} else {
$token = $consumer->getRequestToken();
$_SESSION['REQUEST_TOKEN'] = serialize($token);
$consumer->redirect();
}
} else {
$token = unserialize($_SESSION['ACCESS_TOKEN']);
$_SESSION['ACCESS_TOKEN'] = null;
}

$methodUrl = 'http://ma.gnolia.com/api/rest/2/bookmarks_count';
$rawData = $token->toQueryString($methodUrl, $consumer, array('group'=>'oauth'));
$client = new Zend_Http_Client;
$client->setUri($methodUrl);
$client->setMethod(Zend_Http_Client::POST);
$client->setRawData($rawData);

$response = $client->request();
header('Content-Type: ' . $response->getHeader('Content-Type'));
echo $response->getBody();

You can comment on the formal Zend Framework proposal for a Zend_Oauth at http://framework.zend.com/wiki/pages/viewpage.action?pageId=37957.

Services_Oauth and Zend_Oauth Revisited

nospam@example.com (Pádraic Brady) — Wed, 18 Jun 2008 11:48:25 +0000

With my cryptographic efforts exhausted (I'll wait for the weekend to figure out the intricacies of ext/openssl API changes across 15+ PHP versions), my attention has wandered back to OAuth.

What is OAuth? "An open protocol to allow secure API authentication in a simple and standard method from desktop and web applications" - http://oauth.net/. If you're not yet up to speed it's being adopted by both Yahoo and Google. Interested now?

Starting yesterday, I opened up my IDE, updated PHPUnit, and got cracking. At the current rate of development a Consumer is likely at the weekend. I've already started writing up a formal proposal for PEAR and, of course, the Zend Framework also. I'm thankful the OAuth specification is this simple - it's one of the easiest to read specifications I've had to pleasure to work with. The cost of that is a certain level of vagueness on some points, but nothing you can't overcome with a little reading of the OAuth mailing list.

Of course with any new Specification, there comes potential implementation trouble hard on its heels. Talk about an OAuth Core 1.1 Specification is well underway on the mailing list which drags up concerns over the future compatibility of an early API based on 1.0. I'm not too worried here since these types of APIs are often extremely simple and flexible, very much belying the enormous work and mountain of source code existing in the background.

The other concern are Extensions. OAuth 1.0 allows for Extensions, of which there are several Drafts already. One of the more interesting Extensions is OAuth Discovery 1.0 which will create a dependency (when implemented) on Zend_Service_Yadis (for the Yadis 1.0 Protocol). This Extension will be more formally integrated into OAuth Core 1.1 so it's optional only if you ignore it hard enough! The Yadis component is one of those semi-lost proposals - it's now hitting 15 months on the Zend Review list waiting for finalisation and comment (it has been released on PEAR as beta already).

The other reason this is a bit distracting is that a 15 month old proposal inevitably misses 15 months of clarifications, developments and the rapidly shifting sands of the specification community. For example, Yadis 1.0 Specification is making the move into the upcoming OASIS XRI Resolution 2.0 Specification (Section 6) and there is a new OAuth driven XRDS-Simple 1.0 Specification Draft. These all accumulate unless you regularly assess them all and make incremental changes.

I've had people beating the bushes trying to to flush me out into the open so they can request I get this started. They'll be happy to hear it's now in progress.

Edit: A few people were curious about why OAuth is worth paying attention to. The simplest convincing answer is to point out the alternative. Say you use GMail and a website asks you to import your contact data - how does it access that data?

Do you want every Tom, Dick and Harry website to potentially store your GMail email address and password for some future nefarious purpose? Yet people put their absolute trust in this model day after day on social networking sites.

Do yourself a favour - if you're a developer writing an API make it possible for web sites to access your users' data without having to beg them for their username and so-called secret private password.