This is my application on facebook page.
https://www.facebook.com/SlcChallenge/app_439780382750381
Here my problem is that. Facebook sends signed_request for some user and does't returns
from some user. So when facebook doesn't send signed request my page gets error.
my page tab url is https://tippll.com/pagetab.php/
Please help me to find the solution.
Thanks in advance
Krishna Karki
If on canvas load you receive a code instead of a signed_request, this means that Facebook could not authenticate the user (and retrieve an access_token, and has fallen back to sending a code for you to exchange for an access_token.
Double-check your canvas URL settings in your facebook application. This can sometimes happen if you have URL rewriting non-SSL requests through to SSL domains (or even just url rewrites in general).
Related
I'm working on a facebook tab app. I need to know when the user uninstall the tab app from their page so that I can update my database. While facebook documentation do not specify how that can be accomplished I read that facebook would ping your deauthorize callback url.
On facebook documentation, they say that they will ping the url with a post request sending a signed_request (https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow#logout), but whenever I remove the tab app from a page facebook send a GET request to my callback url without any signed_request, which doesn't help me to know which page had the app uninstalled.
Access log from my apache server
The 302 redirect is happening because there is no signed request.
What should I do? I can't query all the pages on my database to find out which one had the tab uninstalled because it wouldn't scale, I would need the manage_pages permission and there is no way, without a signed request, to know that the request came from facebook.
Try changing the callback URL to SSL. We had this issue earlier this year and when sending to http:// it was always a GET request but once we changed it to https:// it was changed back to a POST request with the signed_request in the body.
I am attempting to implement a simple Facebook login flow for a web application using HTTP redirects, as detailed at https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/v2.2.
For the purposes of making this question generic, let's say the application URL is www.example.com/app.php. On the application page, there is a link which directs users to Facebook's OAuth endpoint, where ideally:
they log in to Facebook (if not already logged in) and approve my application permission to access their public profile
they are then redirected back to my application's URL along with some extra parameters appended (e.g. www.example.com/app.php?code=...&access_token=... if the login was successful, or www.example.com/app.php?error_reason=...&error=...&error_description=... if login/app approval was unsuccessful)
The Facebook OAuth endpoint is:
www.facebook.com/dialog/oauth?client_id=12345&redirect_uri=www.xyz.com/app.php
where I have filled in the client_id and redirect_uri parameters with my application's ID and my application's URL respectively.
What actually happens whenever I access the link is that it immediately redirects back to my application's homepage - without ever showing a login dialog of any kind. This happens with Firefox and with Chrome - both when I am logged in to Facebook and when I am not, in normal sessions and in incognito sessions with no plugins enabled. From the browser inspector, I can see that the Facebook OAuth page is definitely requested but is straight away 302 redirecting to my application page with just a code parameter appended.
www.example.com/app.php?code=...
This also happens when the Facebook OAuth link is accessed from pages other than my application's URL (e.g. if I click the link from www.example.com/other_page.htm).
I am unsure what I am doing wrong here; the application URL (www.example.com/app.php) is approved on my app dashboard in as many places as I could find, and changing the request_uri parameter to any other URL results in an error page. I have also tried urlencode()ing my application URL before passing it in the request_uri parameter, but the result remains the same. I don't know what to try next as as far as I can tell I have followed Facebook's manual login guide as closely as possible.
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've set up my FB app so that it has a Mobile Web URL component. I've noted from testing that whenever I navigate to canvas URL of my app on a mobile device, Facebook automatically redirects the mobile to the defined Mobile Web URL.
If I do the same from desktop, the canvas URL is loaded in to the browser. In other words, if FB detects a mobile device when navigating to an app's canvas URL, it will immediately redirect to a defined Mobile Web URL and not load the canvas URL content.
The problem with this is that when the canvas URL loads, FB passes to it a signed_request form parameter. Yet, when it redirects to the Mobile Web URL it does not.
I noticed when checking a network sniffer that when on mobile Facebook redirects the app.facebook.com URL to m.facebook.com, and thought perhaps the signed_request was getting lost along the way. But when checking the first call to the canvas URL there was no signed_request there either.
It's like Facebook only provides the signed_request when it processes the canvas URL, which in the case of mobile is never.
Has anyone any insight or advice on how to get the signed_request? My only thought at the moment is forcing the user to authorise the app on mobile as soon as they are redirected, but i'd rather not do that if possible (I'm not a fan of gating techniques)
Cheers
Lee
--- EDIT ---
Closing - see my answer.
I've since come to the conclusion that Mobile URLs do not receive the signed_request, and to get the same sort of data requires the users to be put through the FB Auth process. Closing the question.
Your mobile app should be passed a "code" in the query string if the person has authorized your app. Your backend can exchange that code for an access_token and then you can use that to get the current user info by requesting https://graph.facebook.com/me?access_token=[token retrieved from code exchange]. That will allow you to automatically login the current user.
But yes, you do not receive info like the current user's country, locale, and age if they have not authenticated. That is a limitation of mobile web apps currently.
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. :(