Tag Archives: api

Post navigation

If you, like me, have been asked on more than one occasion to write a Facebook login integration for a site, you’re likely to have used the Facebook api library. You also, like me, have had a number of sites that are using older versions of this library which you’ve not had a chance to update – often these libraries are bundled with plugins – for Elgg, the now increasingly ancient “social_connect” plugin is common.

Social_connect, in particular, uses HybridAuth, which is no longer maintained, and itself bundles a rather old version of the Facebook API library.

Anyway, point is, you’ve got some legacy stuff out there. You’ve got the warnings from Facebook about version 2.2 of their API, scanned the changelog and run their migration tool. Today, you’ve suddenly got a bunch of emails from clients saying that the API logins no longer work.

When you take a look, you find that every attempt to log in either spits out an error about no valid User ID being returned or goes into an infinite redirect loop.

How to fix this

It took me a fair amount of digging to track this down, but what has happened is that the API has changed the response format of the request for an access token.

If this was mentioned in the changelog, I missed it. Newer versions of Facebook’s API will handle this, but if you’re using an older version (or rolled your own), you need to change the bit of your code that parses the access token out from the auth code request to handle JSON.

In the legacy Facebook API library, this is found in the method getAccessTokenFromCode() found in base_facebook.php, and you need to replace the following:

Anyway, it is the nature of development that things change, and recently I pushed a patch that fixed a couple of potential security issues. I won’t bore you with the details, except to say that this might well have an effect on how you use the API.

Sessions are destroyed after page display

In the older instance of the API, once you had authenticated, HMAC validation was short circuited and you were treated as logged in on subsequent requests (provided you remembered to store cookies). This was really a workaround to handle the way that Known would forward you to a created object after creation, and since this was a new URL, you’d need a new HMAC, but the 302 would happen before you could generate one.

Now, you are only logged in for the duration of the page visit, and sessions are destroyed after the page has been sent. Each request must now be individually signed.

Which brings us to the next big change..

No more automatic forwards

Because each page request must be individually signed, it is no longer possible to forward you automatically to the created object. It is also no longer necessary for you to configure CURL to automatically handle 302 responses.

Instead, if you’re making an API request, instead of forwarding, Known will return some JSON containing a location for your next GET request, e.g.:

Share this:

Every page on a Known site can potentially be an API endpoint, which means that pretty much everything you can do with the interface, you can write a script or client to connect to.

As things are still being built out there are no libraries, or indeed detailed instructions, out there yet (although you might want to look at some of my samplecode) so I’ve been fielding a bunch of questions from folk.

Overview

At its simplest level, all pages on a Known site are API endpoints.

When you post a status update, the form you fill in POSTs the form fields to the API endpoint /status/edit. So, if you were to write a client to do this, you’d send the same variables to the same endpoint, but you’ll also have to do a couple of extra things as well.

Authentication

In order to access restricted content, or to post to your stream, you will need to authenticate yourself. There is currently only one built in way to do this, however Known supports extensible authentication methods, so it is of course possible to hook in other methods.

For example, if you don’t want to use the built signed HTTP request method, you could use an OAuth2 server.

Get your API Key: from your Tools and Apps page.

Generate a signature: You need to generate a base64 encoded HMAC, which is a SHA256 digest of the path of the api (i.e. if you’re using https://yoursite.com/status/edit, your path should be /status/edit) using your API key as the key.

Tell Known you want the API to return a machine understandable response by sending the following header:

1

Accept:application/json

Some points to remember…

Remember to follow forwards: Known makes use of forwards, for example when creating a post, you’ll be forwarded to the completed object. So, you need to tell cURL (if that’s what you’re using) to follow forwards CURLOPT_FOLLOWLOCATION

Create a cookie jar: In order to preserve your session, and to avoid getting 403 errors after a successful post, you’ll need to store your cookies. Again, if you’re using cURL you can do this by passing the CURLOPT_COOKIEJAR option.