A couple of weeks ago I had the pleasure of speaking at php|tek in Chicago. As usual there were a few great talks, a good crowd of new folk and a selection of established speakers all at the event and I had a great time. This year, there was one particular highlight that I wanted to share: the hackathon.
I've been working with OAuth, as a provider and consumer, and there isn't a lot of documentation around it for PHP at the moment so I thought I'd share my experience in this series of articles. This relates to the stable OAuth 1.0a spec, however OAuth2 has already started to be adopted (and differs greatly). This article uses the pecl_oauth extension and builds on Rasmus' OAuth Provider post. This post is the third in the series, following on from the ones about the initial requirements and how to how to handle request tokens.
This phase is probably the most familiar to us as developers, as it's simply a login form. The consumer will send the user to us at the URL we provided in the request token, and the user will have the request token key as a parameter. The access control on this page will look the same as on the rest of the website; if the user has a session already then the page is displayed, otherwise they must be logged in to see it.
I've been working with OAuth, as a provider and consumer, and there isn't a lot of documentation around it for PHP at the moment so I thought I'd share my experience in this series of articles. This relates to the stable OAuth 1.0a spec, however OAuth2 has already started to be adopted (and differs greatly). This article uses the pecl_oauth extension and builds on Rasmus' OAuth Provider post.
The consumer requests a request token (see my earlier post about consuming OAuth), and as a provider, we need to handle that request. In my example, I chose to pass the variables as GET parameters, but you could adapt this to handle POST variables or information contained in HTTP headers.
OAuth Provider Code
We have the same block of code called on every request where we're negotiating OAuth, and it looks like this:
$this->provider = new OAuthProvider(); // set names of functions to be called by the extension $this->provider->consumerHandler(array($this,'lookupConsumer')); $this->provider->timestampNonceHandler( array($this,'timestampNonceChecker')); $this->provider->tokenHandler(array($this,'tokenHandler')); // no access token needed for this URL only $this->provider->setRequestTokenPath('/v2/oauth/request_token'); // now check the request validity $this->provider->checkOAuthRequest();
Following the principle of "release early, release often", I put live a very early version of the v2 API for joind.in today (so that I can use it in another project!). I haven't updated the documentation yet but in case anyone was thinking of consuming data from joind.in, this at least gives you an idea of the direction of the project so I thought I'd share.
Things you need to know:
- The service is an HTTP Web Service. Meaning it's RESTful apart from when it isn't
- The endpoint is here: http://api.joind.in
- You can fetch data about events and talks (read-only) at this point
- Formats available are HTML or JSON. The service will guess from your accept header but you can override it with
- If you need more columns than you get by default, you can add
?verbose=yesto your request
- Pagination is available, with parameters
resultsperpage(default 20, set to zero for no limits) and
- The service supports OAuth1.0a, which isn't useful at this point as we're read-only but it will come into play as we add functionality
Events list: http://api.joind.in/v2/events
Information about DPC11: http://api.joind.in/v2/events/603
Talks at DPC11: http://api.joind.in/v2/events/603/talks
disclaimer: I am not underestimating the universe's ability to produce idiots, the point I'm trying to make is that I haven't managed to make any deploy mistakes using this approach. Yet.
Once upon a time, a long time ago, I went onto a conference stage for the very first time and said that I thought I might be the world's ditsiest PHP developer. I actually still think that is pretty true, and if you work with me then you will know that I mostly break and fix things in approximately equal measure. With this in mind, when I launched my own product recently (BiteStats, a thing to automatically email you a summary of your analytics stats every month), I knew that I would need a really robust way of deploying code. I've been doing a few different things for a few years, and I've often implemented these tools with or for other organisations, but I don't have much code in production in my own right, weirdly. I decided Phing was the way to go, got it installed, and worked out what to do next.
I've been working with OAuth, as a provider and consumer, and there isn't a lot of documentation around it for PHP at the moment so I'm sharing my experience in this series of articles. This relates to the stable OAuth 1.0a spec, however OAuth2 has already started to be adopted (and differs greatly). This article uses the pecl_oauth extension and builds on Rasmus' OAuth Provider post.
OAuth Pages and Endpoints
OAuth has a little more baggage with it than just passing a username and password to an API. As well as your standard service endpoint you will need:
If you are attending my Web Services tutorial at PHP Community Conference (if not, probably nothing for you to see here) later this week then you might like to download the sample code. I'll be referring to this and inviting you to "play along" as I go creating services during the session on Thursday - see you there!
I've written before about a simple way of patching database versions and there's a much more comprehensive article from Harrie on TechPortal as well. I often find though that projects with patching strategies are missing the scripts to apply these automatically when the code is deployed, so I thought I'd share mine.
My current project (BiteStats, a simple report of your google analytics data) uses a basic system where there are numbered patches, and a
patch_history table with a row for every patch that was run, showing the version number and a timestamp. When I deploy the code to production, I have a script that runs automatically to apply the patches.
I had a funny (funny weird, not funny haha) problem the other day when working with pecl_oauth in PHP to talk to a service. I'd gone through all the handshaking steps, got the acces token and was ready to start talking to the service itself. However when I tried to call OAuth::fetch, I got an error message:
Fatal error: Uncaught exception 'OAuthException' with message 'Invalid protected resource url, unable to generate signature base string'
There are two things to notice about this. The first one is that I should be catching exceptions thrown by this code :) The second is that I could see nothing wrong with my url,
http://api.local. It turned out, after some experimentation, that what is missing here is a trailing slash, and if I supply
http://api.local/, everything works perfectly nicely! I'm unclear if this is intended functionality or not, but if you see this error message and you're requesting a URL with no path info, make sure you have a trailing slash.
Recently I saw some weirdness in an existing application when I upgraded a PECL module that the application depended on. To figure out if that really was the problem, I wanted to downgrade the module to its previous version. There is no opposite command to "upgrade" but you can instruct pecl to install a specific version of a module, using the -f switch to force pecl to overwrite newer modules.
For me the problems were caused in the switch between default functionality in pecl_oauth 1.1.0 (this isn't a bug, but is correct behaviour according to the OAuth 1 spec, I just had code that expected the old functionality), so I wanted to put my version back to 1.0.0
pecl install -f oauth-1.0.0
It was easy once I stopped looking for an option called "downgrade" or something like that :) In fact you can use this trick to install all kinds of pecl versions, simply refer to the package as [package name]-[version]. By default pecl won't let you install packages that aren't marked "stable", but you can install beta packages by putting "beta" in place of [version].
Hopefully now I've written this I'll remember next time how to do it!