Tag Archives: Facebook

Cross Domain Communication, Same Origin Policy and CORS

Posted on by

In computing, the same origin policy is an important security concept for a number of browser-side programming languages, such as JavaScript. The term origin is defined using the domain name, protocol, and port number of the HTML document running the script. It has always been possible for the browser to make cross origin requests by specifying a resource from a foreign domain in the IMG, SCRIPT, IFRAME tags etc. But with these requests the client-side script does not have access to the content of this resource, it can only be executed or rendered by the browser.

The same origin policy permits scripts running on pages originating from the same site to access each other’s methods and properties with no specific restrictions, but prevents access to most methods and properties across pages on different sites. The goal of the policy is to prevent cross-site scripting (XSS), a type of computer security vulnerability typically found in Web applications that enables attackers to inject client-side script into Web pages viewed by other users.

With the growing popularity of Ajax, a group of interrelated web development methods used on the client-side to create asynchronous web applications, the same origin policy became more and more a serious drawback. With Ajax, data is usually retrieved using the XMLHttpRequest object.

Various alternatives have been developed to circumvent the same origin security feature, for example :

  • Flash or Silverlight with a  crossdomain.xml policy file
  • iFrame URL Technique
  • JSONP (JSON with padding)
  • XMLHttpRequest Level 2, which has been merged into the main XMLHttpRequest specification in December 2011
  • XDomainRequest (non standard) used by IE 8
  • window.location.hash hack
  • Facebook cross domain communication channel
  • window.postMessage() : supported by Firefox 3, Safari 4, Chrome and IE 8

With HTML 5, a new web browser technology emerged which defines ways for a web server to allow its resources be accessed by a web page from a different domain. This technology is called CORS (Cross-Origin Resource Sharing), a first working draft was published by W3C.

CORS works on a per-page access-control model. Every page has to respond with a special header, the Access-Control-Allow-Origin header to be accessible by a foreign site.In the CORS model the responsibility of Access Control is in the hands of the developers and not the server administrators. One drawback of this technology is that the Access-Control-Allow-Origin header is not yet supported by Amazon AWS S3. A lot of web designers are requesting this feature on the AWS Developer Forum.

The following list gives additional useful links to websites reporting about this topic :

Facebook URL Linter and Insights

Posted on by

The Facebook URL linter is a tool that helps you to debug Open Graph webpages, pages with embedded like button or with other social plugins.

The Open Graph Protocol Open Source Community developped other tools and parsers for php, java, python, ruby, json to check Open Graph webpages.

It’s even possible to see how many URL’s of pages that are not part of the Facebook Open Graph have been shared by using the API request :

http://graph.facebook.com/?id=http://www.example.com

More details are provided by the API request

https://api.facebook.com/method/fql.query?query=SELECT%20share_count,%20like_count,%20comment_count,%20total_count,%20click_count%20
FROM%20link_stat%20WHERE%20url=%27http://www.example.com/%27

Insights provides analytics on a Facebook Page, app and website. The Insights Dashboard makes it easy to see how Facebook users are interacting with your content, and the Insights APIs allow developers to obtain additional statistics and integrate the data with third party reporting systems.

Valid W3C websites with Facebook Open Graphs or Like Buttons

Posted on by

last update : December 23, 2011
A developer who added Facebook Open Graph metatags or Like Buttons to his webpage finds a lot of error messages (invalid HTML/XHTML) in the W3C Validator. This means it won’t work on a lot of browsers.

Several fixes exist to make the webpages W3C compliant. A few useful links will be given below:

Facebook Feed Dialog

Posted on by

The Facebook Feed Dialog prompts a user to publish an individual story to a profile’s feed. This does not require any extended permissions. Every dialog has a method name and parameters. The URL to a dialog always starts with

http://www.facebook.com/dialog/

followed by the name of the dialog and parameters.

To ask a user to post a story to their Wall, the Feed Dialog with required parameters is used :

http://www.facebook.com/dialog/feed?parameters

The following parameters are available :

  • app_id : required application’s identifier
  • redirect_uri : required URL to redirect to after the user clicks a button
  • from : optional ID or username
  • to : optional ID or username
  • message : optional (see Facebook policies) text to prefill the data field that the user will type in
  • link : link attachment
  • picture : url of picture
  • source : url of media file; if specified, picture will be ignored
  • name : name of the link
  • caption : caption of the link; will appear beneath the name
  • description : description of the link; will appear beneath the capation
  • properties : several JSON objects of key/value pairs; will appear in the post beneath the description; key=string; value=string or JSON object with keys text and href
  • actions : one JSON object with keys name and link; will appear next to the “Comment” and “Like” link under posts

To integrate a Facebook dialog in a webpage, the URL can be constructed on the server or client side. Helper methods are available in the form of Javascript, iOS and Android SDK’s. A Javascript Test Console is available to debug common methods. The tag ?ref=nf is added by the Facebook platform to the links.

Please visit My favorite artist at Leslie’s Artgallery to see a working example of a Facebook dialog.

Facebook Graph API and access tokens

Posted on by

The Facebook Graph API enables you to read and write objects and connections (relationships)  in The Facebook social graph.

There are 14 graph objects available :

  1. user
  2. page
  3. group
  4. application
  5. post
  6. status message
  7. note
  8. event
  9. link
  10. checkin
  11. album
  12. photo
  13. video
  14. subscription

Each object has a collection of properties. The numer of properties is ranging from 4 (min) for the “status message” object to 23 (max) for the ” user” object.

Besides the listed objects, which can be connected to other objects, the following additional connections are defined :

  1. comments
  2. feed
  3. picture
  4. tagged
  5. statuses
  6. insights
  7. maybe
  8. invited
  9. attending
  10. declined
  11. members
  12. likes
  13. source
  14. home
  15. friends
  16. activities
  17. interests
  18. music
  19. books
  20. movies
  21. television
  22. inbox
  23. outbox
  24. updates
  25. accounts

Each object has an individual ID (xxxxxxx) and can be accessed with the URL :

http://graph.facebook.com/xxxxxx

A field query parameter can be used to filter the returned data, for instance :

http://graph.facebook.com/xxxxxx?fields=id,name, picture

Alternatively, the ID can be a name, if defined. The connections, if available, are returned in the same request if the parameter “metadata=1” is added to the request (Introspection). Multiple objects can be fetched in the same request by adding the “?ids=” parameter. A special identifier  “me” refers to the current user.

To fetch a specific connection, for instance who is attending the event zzzzzz, the URL is structured as follows :

http://graph.facebook.com/zzzzzz/attending

All responses are JSON (Javascript Object Notation) objects, a lightweight data-interchange format.

If an object is private, you will receive only the public part of the data or the following error message :

{
   "error": {
      "type": "OAuthAccessTokenException",
      "message": "An access token is required to request this resource."
   }
}

To access a graph object with an active access token (yyyyyy), the following method is used :

https://graph.facebook.com/xxxxxx?access_token=yyyyyy

All calls with access tokens are required to go over HTTPS.

An access token is granted by the concerned user, by the page or by the application. Access tokens are based on OAuth 2.0, an open protocol providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.

In an initial launch, Facebook supports three ways of getting an access token :

  • The default authorization flow is the web server flow for use by server-side developers. The whole flow works by redirecting the user to the authorization server (Facebook) and back to the developer site.  A “Connect URL” with the domain and path of the site must be preregistered.
  • The second method is the user-agent flow in a Javascript based application. Because the code actually runs on the client device, it can’t really rely on embedded secret keys for security – in JavaScript, anyone can look at the source code and trivially extract the secret. The access token is just returned directly in the redirect response instead of requiring an extra server call with specific care for handling security issues.
  • The third method, client credentials flow, is the simplest flow – just exchange your client_id and secret for an access token, no user is involved. It’s mainly supported for accessing application-only resources.

Open Graph Protocol

Posted on by

Last update : June 29, 2013

Open Graph Protocol Logo

The Open Graph protocol enables any web page to become a rich object in a social graph. For instance, this is used on Facebook to enable any web page to have the same functionality as a Facebook Page.

While many different technologies and schemas exist and could be combined together, there isn’t a single technology which provides enough information to richly represent any web page within the social graph. The Open Graph protocol builds on these existing technologies and gives developers one thing to implement.

To turn a web page into a graph object, you need to add basic metadata to the page. The initial version of the protocol is based on RDFa (Resource Description Framework – in – attributes,  W3C Recommendation), which means that you’ll place additional < meta>-tags in the <head> of your the page.

The Open Graph protocol was originally created at Facebook and is inspired by Dublin Core, link-rel canonical, Microformats, and RDFa. It is related to the semantic web.

Facebook Javascript API

Posted on by

The new Facebook Javascript API handles the following methods :

Core methods

  • FB.init : Initializes the library
  • FB.login : Login/Authorize/Permissions
  • FB.logout : Logout the user in the background
  • FB.api : Make a API call to the Graph API
  • FB.ui : Method for triggering UI interaction with Facebook as iframe dialogs or popups, like publishing to the stream, sharing links
  • FB.getLoginStatus : Find out the current status from the server, and get a session if the user is connected
  • FB.getSession : Synchronous accessor for the current Session (less overhead as the asynchronous access)

Data Access Utilities

  • FB.Data.query : Performs a parameterized FQL query and returns a FB.Data.query object which can be waited on for the asynchronously fetched data
  • FB.Data.waitOn : Wait until the results of all queries are ready

Event Handling

XFBML methods

Canvas methods

Some useful tutorials about the new Facebook Javascript SDK are listed hereafter :

  • Mahmud Ahsan on Thinkdiff.net: Graph api & javascript base Facebook Connect tutorial
  • Abu Ashraf Masnun on masnun.com : Using The Facebook Graph API with js-sdk : An explanatory Tutorial
  • timware on Hyperarts : How to Add Facebook’s XFBML Like Button & Social Plugins to Your Web Pages & WordPress Posts

A very useful development tool is the Test Console made available by Facebook.