I just want to ask a question about Facebook "signed_request" thing.
I'm using Zend Framework for my app.
The thing is; when user first authorizes my app OR enters the app from apps.facebook.com/my_app/ URL, I'm successfully retrieving signed_request.
Actually, I'm retrieving it from apps.facebook.com/my_app/index.php (Thanks to this question)
OK, app has been started, I received signed request, stored it in user session. However, when user clicks anywhere in my app, $facebook object is created again but this time, it has no signed_request.
According to this topic on Codeplex, I can expect that signed_request will come in this second request of user:
Instead of using the cookie you should use the signed request value
that Facebook POSTS to your page on each request.
On the other hand, Facebook documentation says:
A signed_request is passed to Apps on Facebook.com when they are
loaded into the Facebook environment
Now, does Facebook sends this request on each call or is there a technical problem on my app? Could it be an IFrame issue? When user click "categories", page is loading in same iframe and URL on address bar does not change.
I think it's basically a difference of definition on what "each request" means. Facebook will POST signed_request to your page only when the containing iframe is first constructed, i.e. when the user goes directly to apps.facebook.com/your_app/somepage.php as their browser location. If the user then follows a "normal" link on your page that results in only a reload of the iframe and not the entire page, no signed_request will be sent. If it helps to think of it this way, signed_request is sent when the user first loads your app, but not on each subsequent request. The reason there is some confusion about this is that many coders have taken a hackish shortcut by making all their links use target=_top and pointing them at apps.facebook.com/your_app/yourpage.php rather than www.yourdomain.com/yourpage.php. Since that results in the entire page being re-constructed each time, it does indeed have the effect of sending signed_request with each page fetch. But in normal (and recommended) operation, you'll need to count on signed_request only being sent once.
Related
I can successfully send app requests by using method: 'apprequests' and the receiver gets the notification properly. I know the page to be shown when the user clicks on the request is the one you put as Canvas URL/Secure Canvas URL.
The thing is I had already set up an App Page for my app, so it makes a lot of sense to lead the user to this page when he/she accepts the request. But I cannot put my app url as Canvas URL because Facebook will not allow it (error: is invalid because it is a Facebook url).
In similar questions, many suggest a redirection but I wonder if there is a more direct/proper way.
I'm serving a list of events to my clients’ website. They include it via php/curl (rather than iFrame), so they can fully customize the CSS.
However, this means that I can’t use the Facebook API to find out wether a visitor of my client’s page is logged in to FB: The FB-API call needs to be signed by an application and shall only be called from the domain the application is associated with. (That would be my server’s domain, but the requests are coming from my client’s page.)
Back in the old days, accessing a user profile on FB would issue a 404 error, if not logged in.
<script type="text/javascript" src="https://www.facebook.com/pianojoe" onload="enable_social_links()" onerror="not_logged_in_to_facebook()" async="async"></script>
That was convenient, but FB took care :-/ of it.
I want to show FB-links for the events in my calendar only if the page visitor is logged in to Facebook.
My question: How do I find out if a page visitor is logged in to Facebook if I can’t determine the domain of the referring page beforehand, and therefore not use the Facebook API?
The Facebook PHP SDK has a (relatively new) method called getLoginStatusUrl.
It creates a simple URL that you redirect the user’s browser to, which takes them to Facebook, where his login status is checked, and then redirects them back to one of three different URLs of your app, that you can specify.
ok_session is the one that you would be mainly interested in here: “URL to return if the user is logged in to Facebook.”
(The other two are no_user for when the user is logged out of Facebook, and no_session for when Facebook themselves can’t figure out the user’s status, because there’s no user-specific FB cookies whatsoever set in their browser.)
So you could set ok_session to an URL of your application with an additional GET parameter like ?logged_into_fb=true (the other two options, if not specified explicitly, will then only redirect back to your app’s base URL) – and that way, when the user is redirected back to your app with that parameter, you know they are currently logged into Facebook.
Whether or not you are actually using the FB PHP SDK does not really matter – by looking at the source code of the method it’s relatively easy to figure out how the actual URL is build, so you could easily adapt that and use it without the SDK as well.
Situation: I am developing a facebook canvas app. Facebook is sending my sever a POST request with the signed_request each time that a page is render. Inside my app I have all my links with target="_top" because if I don't, facebook send my server a common GET without the signed request. So I cann't check the user info.
Problem: It is too slow! even if I am testing it in local, each click that I press takes 1 sec to render and my canvas becomes completely white and then the info is shown, It will be a bad user experience.
My tests: If I remove the target=_top and I point all my links' href to my server without the app.facebook.com/whatever, it loads very quickly.
My doubts: Is there any security issue with this? If I point all the links to my server (no apps.facebook.com) I can not check the signed request, I will only check it in the main page..
Any advice? any tutorial? Do I have any misundestanding of this? (It is my first facebook app)
Have you read the Server-Side Authentication tutorial?
You're doing it wrong.
Once the users lands in your app you should keep all links in the same frame, loading the entire window along with facebook is completely redundant.
What you should do:
When you get the POST with the signed request, decode it and check if the user is authenticated, if he is persist the data (token and such) somewhere (session, db, cache).
If he is not authenticated send him to the auth dialog as noted in the tutorial, when he gets back exchange the code you get (in GET) for the token (also shown in the tutorial), then redirect him to http(s)://apps.facebook.com/YOUR_APP and you'll be posted with the authenticated signed request, save it, etc..
Since you persist the data, in every request that is not POST or don't include the signed_request check your persistency choice for the data, and use it.
There should be only two times where facebook sends you the request, once it is POST when your canvas is loaded, the 2nd is when the user returns from the authentication dialog, in which you either get the code parameter or error in case the user declined the authentication.
Other requests should be from your app (inside the iframe) into the app servers.
JDL,
I believe you are querying the graph API at each request (and that's why you always need the signed_request). Is this right?
The graph API is pretty slow (~ 1 second/query) and you should use only when necessary. For example, when you first receive the access_token you should save it in your session and query the graph API to retrieve the respective facebook user info. But then you should put the info you need about this user in your session and only refresh it (using the graph API) when the signed_request access token is different from the one you have saved in your session.
The behavior of adding _top to the target of your links is ok and a good practice within facebook canvas.
With the changes for Facebook Apps coming on October 1st, I am having trouble confirming that our Canvas/Tab app will/will not work as expected.
When a user first loads the tab with the app, I'm expecting facebook to send me parameters of "fb_sig_profile_id" (which I believe should be the ID of the Page) and "fb_sig_app_id" (the ID of the APP).
I DO NOT need/want to authenticate users or access UserData/Graph etc. I am simply displaying content on my end based on these parameters.
If this is no longer the case and Facebook is not going to be sending me these parameters, can someone point me in the direction of how I can get this data.
Thanks
When building Apps On Facebook kind of apps, Facebook will send a signed_request which will contain the data you need:
When a user navigates to the Facebook Page, they will see your Page
Tab added in the next available tab position. Broadly, a Page Tab is
loaded in exactly the same way as a Canvas Page. Read more about this
in the Canvas Tutorial. When a user selects your Page Tab, you will
receive the signed_request parameter with one additional parameter,
page. This parameter contains a JSON object with an id (the page id of
the current page), admin (if the user is a admin of the page), and
liked (if the user has liked the page). As with a Canvas Page, you
will not receive all the user information accessible to your app in
the signed_request until the user authorizes your app.
Reference.
I have a page tab application. Sometimes when a logged in user clicks the tab name from the Facebook page, the form post "signed_request" data is being passed in is empty.
Any ideas as to how this can happen? It is sporadic and doesn't seem to be locked to one specific user account. I have oauth2 set to true in the settings, so according to Facebook's api documentation, I should always be passed signed_request in the form post data.
Had a similar problem, was helped by:
Cannot access Facebook signed_request with an iframe tab
In my case the site hosting the app was doing a 301 redirect because the app url I gave Facebook contained capital letters. The redirect changed POST to GET and lost the signed_request.
Here's the work-around I've figured out.
*If there is no signed_request form post parameter, then I display an error screen to the user and ask the user to refresh the page. This usually fixes the issue on the second request, and the page is sent a proper signed_request form post.*
Lack of Facebook support and involvement in the facebook stackoverflow section is very disconcerting. It wouldn't be that bad, if it wasn't that Facebook had mandated use of this forum for the entirety of their API support. :(