Facebook is a popular social network where you can write your application. I do not like to push the water in a mortar, so immediately to the point. You can embed in two
directions : external application in Facebook or Facebook data in an external application (aka
Facebook Connect ). Here I will talk about the first, which is basically more time consuming and interesting. As a rule, the meaning of a facebook application carries two functionalities - interaction with friends and informative integration into a user profile.
The basics
You can embed the application in the following
places ..
- Canvas - the actual page with the application. Available from the link apps.facebook.com/PROGRAM NAME
- Profile box - a small box inside the user’s profile
- Profile tab - new tab in profile
- Boxes tab - a small block in tab boxes
- News feed - access to the stream of updates
- Requests box - interactive messages to other users
Integration is made by mixed
features ..
- REST API (http://api.new.facebook.com/restserver.php) which gives “hard” access for the backend with the ability to upload photos, videos, get lists of friends, events, comments and so on.
- FQL is a way to request REST data not only through method parameters, but already through an SQL-like syntax
- FBML - HTML stripped down its own tags, which Facebook interprets in a window in its own style and design and caches during in-line display. A bunch of problems with built-in tag validator
- xFBML - FBML tags used in your application
- FBJS - JS Trimmed
Two ways
Now that the basic terms are clear, let's move on to the application itself, which is located in the Canvas. After creating a new application through the
developer app , downloading the
REST library for php, uploading the application to your site and installing the URL settings for the Canvas, you can see that there are two ways to launch it —
iframe (+ XFBML) or
pure FBML that will be stored on facebook. Naturally the first option is the easiest. After creating the program and adding / confirming in your profile, the display of the Canvas will be accompanied by the usual iframe + GET parameters with the prefix fb_sig_, of which the most important is fb_sig_canvas_user. The second option is more dreary, but more closely related to FB.

')
The rights
Now we need to think about what the application does in principle. In my case, this is a quiz test - the user answers the questions and at the end the status is put on the wall in a profile (profile wall).
First of all, it turns out that it is very useful to have user confirmation for receiving data (
Authorization ) which is called by the method
Facebook :: require_login and for the user looks just like a window
transfer of rights. Having rummaged in the documentation for the publication of data in Wall (News feed), there is a method
Feed.publishTemplatizedAction , but it turned out that it is outdated (deprecated). The alternative is
Stream.publish , and now we
come to the second important topic -
Extended permissions .

Without rights, the request will simply receive a fatal error. In order for the program to have a deeper access over the profile
user, the latter must confirm this separately in the dialog
window And to cause this dialogue to post a message on the wall or
changing the status of a user is not so easy.
$facebook->api_client->stream_publish("My new status");
Uncaught exception 'FacebookRestClientException' with message 'The user hasn't authorized the application to perform this action' i
Now a few subtleties - the documentation in the wiki and forums should be read with great suspicion, because often
Obsolete code is encountered (for example, the names of the privileges / methods of stream_publish instead of
publish_stream). Methods for checking privileges give either a fatal error or an unintelligible reply to the parameters, including the test
API consoleif($facebook->api_client->users_hasAppPermission("publish_stream")){
//
}
FBML temptation
By this time, the advantages of the FBML mode (compulsion to a similar interface and the supported FBML tags) become clear. I still worked
xFBML
It is clear that the rights to receive via the iframe are thus buggy, I want to live simultaneously and separately with Facebook. To do this, there are xFBML-tags that are interpreted by Facebook javascript. Total need in your application need:
- Enable static.ak.connect.facebook.com/js/api_lib/v0.4/FeatureLoader.js.php javascript
- Make xd_receiver.htm
- Initialize with your api-key
- Specify the path to the root in the settings of the Connect-application on Facebook
Now you can ask right
FB.Connect.showPermissionDialog('publish_stream');

Lost donkey cookie
You can not get around without mentioning IE 6/7 and here. The fact is that the default iframe in these browsers loses session variables. Simply put - cookies do not reach the server, because the iframe is considered “unreliable” content and it even shows an eye in its status bar. If you understand this in
detail , then there is a justification for this in the form of the
W3C platform for privacy preferences . For this, it is easier to add a title.
header('P3P: CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"'); //for IE6/7
In the end, the application successfully updated the profile (where it was possible to shove and picture through the attachment)
Original