All I want is to find at least one working solution for this simple thing.
I want to determine what facebook user making request to my FB canvas application. I also want the mechanism to take into account cases when user logs off or re-logs on.
I've really broken my head on that :(
Ways i've already tried:
1) Getting and parsing signed_request param while user's initial request to the application. Cons: the canvas main page is the only place to get it. I never know what user is doing next actions.
2) Using fbsr cookie. Cons: sometimes i get error when trying to exchange cookie's code to user's access token. I still cant reproduce it, it just occurs. Btw, does it work at your?
3) Handling every get/post request at client side and adding user's access token being retrieved by JS SDK to the request. Doesnt seem to be a good way.
Well, that's it. What im doing wrong? Will be thankfull a lot for any working solution.
1) Getting and parsing signed_request param while user's initial request to the application. Cons: the canvas main page is the only place to get it. I never know what user is doing next actions.
Well then just put the parsed signed request into the session …
That’s what I usually do – every time Facebook::getSignedRequest results in something other then null, I write it into my session (so I don’t miss if it gets updated, f.e. by the user liking the page).
Related
when I do a get request to
https://graph.facebook.com/[userid]
with the access_token i get all the basic info
but when I do
https://graph.facebook.com/me
with the same token i get an error message: An active access token must be used to query information about the current user
I have tried to under stand what can cause that.
I even tried to token that comes with the signed request
I'm on classic asp, with JSON library, I want the auto to be server side if possible. the FB.api("/me" is working but it is not what i really want to achive
I am pretty sure you don´t have a user access token. Did you login the user? Of course you get the public data of every user with your first link, even without any access token. You can even put it directly in the browser and will get results. But for "/me" you have to authorize the user to your app.
See here: https://developers.facebook.com/docs/howtos/login/server-side-login/
It is the same problem as in the other thread for sure, just a different Programming language.
Remember: If the user did not accept at least the basic permissions in a dialog or redirect, he is not logged in and you will never know anything about him in the app (except for some specifics in tab apps, like language, like-status and stuff).
So I'm building my app around facebook oauth, and was hoping to use the fbsr_ token to identify logged-in users (so that the facebook-js stuff stays in sync with my site).
Unfortunately, it appears that these fbsr_* cookies are set to expire within a day. Which means if the user comes to my site a day later, they have no cookie and are shown a logged-out experience.
The facebook-js then runs, recognizes them, creates the fbsr_* cookie, and gives me a callback. I can choose to do a hard page refresh (rather jarring), or try to do fancy in-place ajax updating (tons of complex code, still slightly jarring). Is there a reason these cookies don't have a longer expiration so the user stays logged-in seamlessly? Most websites allow you to "remember me" when you log in to avoid constant cookie expirations, so I'd rather not have my facebook-enabled website keep logging me out.
Is there anything I can do about this? I suspect I can probably switch to serverside-oauth where I manage identity and cookie expiration myself (yes?). But it seems strange that clientside-oauth would have such a limitation, so I'm hoping I'm missing something.
Is there anything I can do about this?
No, not really.
The only way to determine, if a user is currently logged in to Facebook, is to look at the cookie set for the domain facebook.com.
The JS SDK is capable of doing that, because it runs client-side, and can make a cross-domain request to check if these cookies are set.
But there is no way to check for those cookies server-side from your domain – your server only has access to cookies set for your own domain.
I suspect I can probably switch to serverside-oauth where I manage identity and cookie expiration myself (yes?)
If your set your own cookies on your domain, you are implementing your own login system.
And even if you “fake” the cookies that the JS SDK sets under your domain, it would not bring the same results.
There might be a cookie on your domain, that says, “yes, user XYZ is logged in to Facebook” – but that would not have to be the case. I could have logged out of Facebook in the meantime, and your cookies would not reflect that at all. So whatever you’ll try to do next, like f.e. posting something on my behalf from your app, will most likely fail, because you only think I was still logged in to Facebook, but in reality you do not have a valid access token for me any more, since I am not really logged into Facebook.
The facebook-js then runs, recognizes them, creates the fbsr_* cookie, and gives me a callback. I can choose to do a hard page refresh (rather jarring), or try to do fancy in-place ajax updating (tons of complex code, still slightly jarring).
Those are your only viable options.
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.
I'm getting into the grimy guts of a problem that has turned out to be rather cumbersome so I turn to you, the experts, for help.
what I've done so far: I am building an iphone app with phonegap. I am using the provided fbconnect (in phonegap github) code which gives some rather convenient javascript based example code to build things like a comment and check in request. I have comments and checkins fully working how I want, and I have an auth_token that I am successfully toting around.
enter the like button: I understand that you cannot make like requests via xmlhttprequest in the same way that you can with comments for example, so I am stuck using an iframe (unless there is a better alternative).
what I need help with: right now, since the iframe is triggering its own login, I have the situation where the user might log in to like, and then have to log in again to comment which is not a viable. Is there a way to pass a valid auth token to the iframe so the user wont be prompted to log in again or some other sneaky way to authorize through the childbrowser solution that I have currently implemented and then share the auth token to the rest of the app?
notes: I havent passed an app ID to my auth implementation but I noticed that the iframe does pass an app ID. would including an app ID in my auth request somehow link the logins so facebook could recognize that the user is already logged in through the app?
I can't think of any specific code to include since this is more of a general question but if there is anything you'd like to have a look at please let me know.
The short answer is no, mainly for security and spam prevention. The only way to have the user like your page is rendering the iframe code in a webview. This requires a traditional email/password login with Facebook. Using the graph api is the only way to use things like commenting and checkins, and this requires a user to login via a separate mechanism and then subsequently approve your app. There is no back door logging in mechanism.
I have a Facebook Connect app that I monetize using Google AdSense. I want to be sure that I am not leaking any Facebook user information such as the Facebook UserID number or the access token (which has the UserID in it).
AdSense is perfectly legit and within Facebook policy for Connect applications. I just need to be sure Google cannot see the information that identifies the user.
I was well aware of these requirements when I designed my application, and thought I had it nailed, but then I received one of the famous automated warning emails from Facebook stating:
"Our automated systems have detected that you may be inadvertently allowing authentication data to be passed to 3rd parties."
it also stated:
"In every case that we have examined, this information is passed via the HTTP Referer Header by the user's browser."
Again, I was already familiar with this leakage vector, which happens when Facebook puts the access token into the querystring when it redirects back to your app after user authentication. I already have a design in place where I handle this through server-side OAuth 2.0 redirection, obtaining a "code" and exchanging it for an access token. This method is described here, under server-side authentication: https://developers.facebook.com/docs/authentication/
In my app, I do the code-for-token exchange in a separate ASP.NET MVC controller that has no views, so there is no Adsense or any 3rd party resources included. So I am certain that all of my header referer field contents and querystrings are clean and contain no user data.
Given that I received the email notice from Facebook however, and don't want my app and the AdSense money faucet turned off, I am now paranoid that there is some other place I am leaking data. Then again, the email says my app "may be" leaking information (why oh why can't they just tell me what they saw, or at least be certain it is leaking rather than it just "may be" leaking), and it says every instance was due to the referer/querystring, which again I am certain (having done Fiddler tracing) my app is clean.
I see only one possible way the info could be leaking, but I'm not sure if it is a real risk or just a lack of understanding on my part of what exactly AdSense (and Google Analytics) can see from my app's content on a page that requires the user to be authenticated.
I have a view (page) where I put the access token into a hidden form field. It is put there when the page is initially served up (after the user has been authenticated), and then subsequently updated via Javascript (using the Facebook JS SDK) so when the user posts the form back to the server, I get an updated access_token if it has changed. The access token can change because I use the Javascript SDK to prompt for additional permissions on that page, including in some cases the offline_access extended permission. Getting offline_access will generate a new access_token, one that does not expire.
This is on a page that requires the user to be authenticated to see it, so I figured AdSense cannot see the page contents. I do have the view setup to render in a generic fashion (no user info) with all of the same text if the user is not authenticated, but with the addition of a "login now" prompt, so Adsense can index the page and provide relevant contextual ads.
I am aware of the fact that Facebook just yesterday launched the new OAuth 2.0 Javascript SDK features, but can't adopt that right away as it won't work with the Facebook C# SDK I use server-side. And even with that, if I have a problem with putting the access token in the hidden form field, that problem would still be there.
In classic Facebook fashion, they give me 48 hours to fix the problem, but any inquiries via their developer support web form only result in a response that they will "do our best to respond to your specific issue within one week."
Maybe a simpler way to think of this problem is "can Google AdSense see the page contents of a page requiring user authentication?" or do they only see the header referer field from which the AdSense javascript file was loaded.
Hard too say exactly what they have detected without knowing the details of your code - but I would guess that may is actually does leak information. They would have identified a particular pattern that they know will leak, and they have spotted that pattern to exist in your app
Why don't you setup a proxy server such as squid and then point your browse to go through your squid instance for all http access. You can then look at the squid logs for all the http requests and headers for any indication of what may be leaked?
I would think you should pick an independent machine for installing squid, so an amazon micro instance may be what you need for this if you don't already have a machine available
In addition all JavaScript running on the page can see everything in the DOM and all global JavaScript variables so if you/Facebook are worried about leaking info that way you may want to store all uid inside a closure and/or run the adsense code in a iframe rather directly in the page - as a general shrift rule, you should never allow 3rd party JavaScript code to run in you page without it being wrapped in a iframe
They got back to me after a manual review of my site and said it was not actually leaking any user info. Gee thanks for the runaround Facebook automated detection systems!