LornaJane
Blog
I'm working on some demos for a tutorial I'm giving next month and since I'd like to show off Github's API, I needed an access token for it. They have the usual web flow but I'm cutting as many corners as I can to keep the demos nice and quick, so I looked into the support Github has for generating an API key programmatically. Continue reading
I've been working on something recently where I'm pulling information from lots of places onto a dashboard. Each API has its own little quirks so I'm trying to write up the ones that weren't idiot-proof, mostly so I can refer back to them later when I need to maintain my system!
I've written about Google and OAuth before, but that was OAuth v1.0, and they are introducing OAuth2 for their newer APIs; in this example I was identifying myself in order to use the Google Plus API (which turns out not to do anything you'd expect it to do, but that's a whole separate blog post!). Continue reading
I had an issue this week on a system which has been working fine for a while, but stopped fetching some data from google's user account API. I was getting a 403 response from the API, which seemed odd. Luckily I was logging OAuth::getLastResponse() to my error logs (this is PHP code, and you need to call OAuth::enableDebug() before you make the request to get this output) so I could see that I was getting the following back from Google:
<?xml version="1.0" encoding="UTF-8"?> <errors xmlns="http://schemas.google.com/g/2005"> <error> <domain>GData</domain> <code>sslRequired</code> <internalReason>SSL is required to perform this operation.</internalReason> </error> </errors> |
Closer inspection shows that for one of the google endpoints, I had a prefix of http:// rather than https://. Those single-character bug fixes that take hours to find are my favourite!
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 entry follows on from the ones about the initial requirements, how to how to handle request tokens, and authenticating users.
Continue reading
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.
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:
?format=json or ?format=html?verbose=yes to your request
resultsperpage (default 20, set to zero for no limits) and start (default zero)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
Comments are welcome on this post. Bugs and feature requests should go to http://joindin.jira.com, read more about Joind.in and its community at http://joind.in/about
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 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:
Continue reading
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.
It is pretty common when using OAuth for there to be a relationship between the provider and consumer; as a consumer you usually register with the provider to obtain a consumer key and consumer secret. Google's APIs however do not require this. It is recommended that you register your application, however it is also possible to use OAuth without registering.
To make this work, when you sign your OAuth request Google will accept some default values for consumer key and secret - see their documentation on signing oauth requests. To do this, set both consumer key and secret to the value "anonymous", and proceed as you normally would. The only difference so far as I can see is that the user will be shown a more cautious message when they are prompted to grant access to your application. Personally I think this is a great approach, particularly when prototyping ideas. Registering the applications though is simple and quick so I'd recommend registering for most applications once they get beyond concept stage.
© 2006-2013 LornaJane.net Icons courtesy of The Noun Project