OAuth Middleware for Slim

OAuth can be anything you want it to be, the standards are lax and give you plenty of room for getting the right implementation for your system. However you proceed, though, you'll need to check an access token on every request - and in a Slim application, a middeware can help enormously since it hooks in to every request by design. I've recently implemented this and thought I would share. Continue reading

Twitter Search API Using PHP and Guzzle

In case you missed it, Twitter updated their APIs recently, so that you have to authenticate to use even their search APIs to return publicly-available results. This is an increasing trend for API providers, to provide either very limited or nonexistent access for unauthenticated users, I think so they can rate limit consumers that swamp them. To cut a long story short, that meant I needed to update my dashboards that keep an eye on twitter searches to do more than just call file_get_contents in the general direction of the right URL. Continue reading

Github API Access Tokens via Curl

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

Using OAuth2 for Google APIs with PHP

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

Google OAuth 403 Response

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!

PHP OAuth Provider: Access Tokens

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

PHP OAuth Provider: Authenticate User

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.

Continue reading

PHP OAuth Provider: Request Tokens

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();

Continue reading

A Prototype API for Joind.In

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 ?format=json or ?format=html
  • If you need more columns than you get by default, you can add ?verbose=yes to your request
  • Pagination is available, with parameters resultsperpage (default 20, set to zero for no limits) and start (default zero)
  • 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

Examples

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

Your Thoughts

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

PHP OAuth Provider: Initial Requirements

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:
Continue reading