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
Popularity: unranked [?]