Tag: facebook

If you want to retrieve public data from Facebook (typically a Page) you nowadays will have to use Facebook Graph API and thus provide an access-token. In the old days you could use some of the available feeds (following the RSS-principles) but that was back then.
I’ve seen some strange hacks around, but it’s quite simple to pull public data with a non-expiring access-token. (Impatient ones go here!)

Access-tokens in short

The idea behind access-tokens is that the system you’re communicating with ‘knows something about somebody’; is that somebody a valid logged-in user, what is that user allowed to do, etc. For every request your application makes, on behalf of that user, you pass that access-token to the system.
Access tokens typically expire; to reduce the chance of getting in the wrong hands (Facebook offers appsecret_proof to prevent hijacking). When the user uses the application access-tokens get renewed in the background, when the user doesn’t use the application before the access-token expires, a new login / authorization action will provide a new one.
Facebook Graph API knows short- and long-term access-tokens, where the short-term tokens are used by the application’s client and the long-termed by the application’s server (using an app-secret).

Let the app do the talking

The access-tokens mentioned above are “user access-tokens”. If you just want to pull out some public data, having users logging in and expiring access tokens is probably not what you want. But you can also in make requests to Facebook’s API on behalf of an a Facebook App, in stead of a user, working with an “app access-token”.
When you create an app at Facebook for developers, you have an app-id and an app-secret. In stead of requesting “oauth” for an app access-token, you can construct one yourself  by combining your app-id and app-secret, when requesting from a server (not client!!), like this:

Note: using “appsecret_proof” doesn’t make much sense here

Let’s get practical

I needed to display posts from a Facebook Page via Javascript (with Ember.js to be exact). No further Facebook interaction was needed, so user access tokens were not what I was waiting for, I needed an access token that does not expire, and that I’m in control of, not some user. So I opted for using the “app_id|app_secret”-solution with an app access-token, mentioned above. That I had set up as a proxy on my webserver. The flow now is: Client -> Webserver -> FB API -> Webserver -> Client.

Here’s the method I used at the webserver (in PHP) to make calls to Facebook Graph API

Load the Facebook data in Ember.js

For the ones interested in how you easily can work with the requested Facebook data in Ember, stay tuned and I’ll provide a snippet for your serializer.
Of course we’re using Ember Data to handle all this. First of all, model your data by adding a new model. You will at least have to define those attributes corresponding the fields-parameter from your API request.
For example ‘message’,’created_time’. Now setup your adapter, connecting to your ‘proxied webservice’.
When the data comes back to your client and back to Ember, Facebook has a slight different JSON-format than Ember expects, so we have to serialize it a little.
And what Ember expects depends whether you’re using the ‘old’ or ‘new’ adapter for handling JSON.
The previous de facto standard was the Ember Data RESTAdapter, the current de facto standard is the Ember Data v2 JSONAPIAdapter. What do they expect:

• RESTAdapter: {“modelNamePlural”:[…]}
• JSONAPIAdapter: {“data”:[…]}

Ember Data RESTSerializer (using the extractArray method)

Ember Data JSONAPISerializer (using the normalizeArrayResponse method)

This is the model I’m using
Model

The fields comment_count, like_count and share_count do not exist in the response from Facebook, they’re nested in ‘comments’, ‘likes’ and ‘shares’ objects. With the serializer’s normalize method you can make the response-data fit into your model.
Another thing I did here is adjusting the date-format given by Facebook, as Moment.js by default will fail with that input on Safari and IE, when there’s no colon in the time-zone.

Add this method to your serializer (either RESTSerializer or JSONAPISerializer) to get the model straight: