Pulling Facebook events into EPiServer
We all want EPiServer and Facebook to play nicely. In theory they should, but the integration suffers where Facebook is a bit ‘person orientated’ where EPiServer is ‘enterprise orientated’. This can make things that should be simple a bit more complex.
For example, one common thing to do would be to create a Facebook page for your organisation. Let’s say it’s “Paper Bag Dating” and your website is www.paperbagdating.com (you can try and click if you like, it doesn’t really exist!). On the Facebook page you create your dating events, and you want them pulled through to your website. Ideally you’d want a custom page provider but if you can’t stretch the bucks then at least you’d want a scheduled job importing the events as pages.
So far so good, but when you use the Graph API to get the events for Paper Bag Dating (more on the Graph API just now), you cannot get the events without being authenticated:
"message": "An access token is required to request this resource.",
The reason for this is that while the main Page is public on Facebook, everything on it can only be accessed with an Access Token. That you can only get by being logged on. So where we are at is this:
You can only access Event information on a Facebook page when you are ‘on the Graph’.
So we need to get on the Graph – which is a Facebook term that just means their social network. You can only do this as a person, and so you’re going to need a ‘proxy user’ that has access to the Page you want to pull events from. That would be straightforward, except that there is no way to just ‘log on’ to Facebook via an SDK using a username/password combination. You can only get onto Facebook using an Access Token, and that Access Token you need is tied to a Facebook App. So – yes, you guessed it – we need to create a Facebook App. We’re not actually going to create a full-blown App as such. We just need to create a ‘container’ which we will use to route our requests through to Facebook. You can think of an App as the ‘gateway’ to Facebook.
Thankfully, it’s not hard to create an App. Just go to Facebook’s App creation tool. You’ll need to enter a name for it and a website etc. The only really critical things are the domain and site app url. I would suggest that you put the domain as your site, e.g. www.paperbagdating.com, and the site app url as a subfolder, e.g. www.paperbagdating.com/fb. I will come to why you need those in a moment. One other thing you’ll probably want to do is edit your App settings and turn ‘sandbox mode’ on. That means only you, and other App admins, can see the App. As we are just using this App to get our Access Token, it’s probably a good idea. Remember, we’re only interested in the ‘proxy user’ generating our Access Token anyway.
At this point we need to create our App. Facebook’s Graph API uses oAuth and JSON heavily, and so you can grab libraries for those and cut your own App if you like. I used the Facebook C# SDK on codeplex as it already has those libraries wrapped in, plus some other helpers. It’s an SDK to create Apps, and is fairly lightweight. Note that the documentation isn’t exactly great and the code samples on the linked blog posts are wrong, but the example project on github is a good reference source.
Once you’ve pulled the Facebook SDK, you can create your App. To start, simply create that ‘fb’ folder on your site (or whatever else you’ve chosen) and inside it create an ASPX page (it can be a standard ASP.Net page, it doesn’t need to be an EPiServer template page). The reason I suggested creating a subfolder is because you should lock this folder down using a ‘location’ statement in your web.config. Even though this App is going to be used purely as a ‘gateway’ to Facebook, I personally would like to keep it under wraps.
Now you have your ASPX page, you are ready to authenticate and get your Access Token. The way that Facebook works is to show it’s own dialogs to log you on and grant permissions to the App, and unfortunately because of the way oAuth works, this is unavoidable. What we will therefore do is set a redirect URL so that the control comes back to us at the end. We simply ask Facebook to authenticate us and then return control, as in the sample below, commented ‘stage 1’ (note, my ASPX page is just called ‘app.aspx’). A couple of things to note – the AppId needs to be set to the one that you were given when you created your Facebook App. Also, I’ve added one extended permission, “offline_access”. This means that the access token created won’t timeout any time soon, and the user doesn’t need to be online for me to use this access token. That is the only permission I need to read Events, but you can add other permissions as you need.
Facebook will now handle all the authentication, permission granting acceptance etc. and then redirect back to the URL we passed through complete with some extra QueryString parameters, either the Access Token or an error message. You can do what you like with the Access Token. Personally, I just want to display it so that I can copy-paste it where I need it elsewhere. The code-behind therefore looks as follows (I have just one control on my ASPX page, a Literal control called litMessage):
We can now use our Access Token wherever we like. I wrote a simple Admin mode plugin and a DDS-compliant settings class to set and store my Access Token. You could do that, or use web.config, whatever you like. To show how we now use our Access Token to pull data, I’ll show you my implementation of the Event import (this is an Entry license so I didn’t have the luxury of custom page providers).
I wrote a scheduled job that pulls all the events for my dating page and checks to see if they are already existing under my ‘Events’ page on EPiServer. If they aren’t, it creates them. This is fairly dirty code and I’m not using Page Type Builder here, but it will give you an idea of how it works. Just a few points to note first:
- The Graph API, despite the fact that Facebook say that they are deprecating the old REST API, is still pretty much REST based insofar that it’s HTTP verbs with the addition of parameters. You pass through what you want and get JSON objects back. A very useful tool is the Graph API Explorer to work out what calls you need. In this case, I am using ‘PaperBagDating/events’.
- As with all JSON calls, they are loosely typed so you need to refer to the Facebook Graph API to make sure your casting/parsing matches what you need.
- You’ll notice that I’m passing through my Access Token and accessing the API, even though it is nothing to do with that App I created any more. This is fine – as far as Facebook is now concerned, it is that App that is doing this stuff (the Access Token is linked to my Facebook user and the App).
- The ‘FacebookSettings’ class is just my simple DDS-compliant class for persisting the settings
We are now done. The scheduled job will run and, using the Access Token we generated with our Facebook App, will pull in all the events from the PaperBagDating page and push them into EPiServer. This could be expanded to much more, naturally – like RSVPs, updates to existing events and all the rest, but it shows the concept well enough and I prefer to keep things simple anyway. I have this scheduled job running every five minutes, and here is an example of the output:
I’m toying with the idea of expanding this, maybe cleaning it up and putting it on epicode. I can see how this technique could be used to integrate lots more between Facebook Pages and an EPiServer site. If anyone has any other ideas, or knows a far easier way to do this, please do let me have your feedback.