In old API the init function required path to xdreceiver and now i see it disapeared from docs.
I thought the xdreceiver is for seting cookies in your domain from facebook, but how it's working now?
Assuming your talking about an external or iframe Facebook application then Facebook uses the OAuth2.0 system and stores a cookie on your server of the form fbs_APPID where APPID is obviously the application id of your connect/canvas application.
Inside this cookie there is an access_token which is used to by both the old rest API and the new graph API to make requests on behalf of the user. This means the xdreceiver file is no longer required.
See the Facebook Developers article on authentication in OAuth2.0 here
Canvas applications can also take advantage of a new experimental signed request in order to receive the access_token.
That file is not required anymore. My understanding is that they store cookies on their side in database somewhere and then emulate cookie headers when sending HTTP requests to your app, so to your application it seems like regular cookies from a browser.
You can read briefly about cookies here, couldn't find anything better.
EDIT
Seeing BeRecursive's answer, I want to clarify that I was talking about cookies that you manually set from your canvas app. Maybe it's not what you asked about.
Related
My question is related to, but not exactly, this question.
I am currently working on a business directory Web site (similar to Yelp), in which businesses have their own pages. Let's call this app DIRECTORY_APP.
Businesses might want to have their latest Facebook status update shown on their pages hosted on our directory. Let's pretend we have a business named BIZ_1. The assumption is that those pages are public pages.
Apparently the Facebook Graph API can be used for this purpose. So I can send a request to Facebook to retrieve the latest status updates for BIZ_1:
https://graph.facebook.com/BIZ_1_PROFILE_ID/posts?
access_token=DIRECTORY_APP_ACCESS_TOKEN
&callback=callbackName
However, if I use this from the client side, our Web site's access token will be exposed to the public, so this is not a reasonable solution.
Now in the aforementioned question, Anatoly mentions that we can retrieve the access token by sending this request first:
https://graph.facebook.com/oauth/access_token?
client_id=YOUR_APP_ID&client_secret=YOUR_APP_SECRET
&grant_type=client_credentials
However if someone inspects the Network log, this will also expose our Web site's access token (is this correct or is this a different type of access token?). This solution also exposes our web site's app secret (is this safe?).
So to summarize, what's a safe way in which I can retrieve the latest status update of a Web page from client-side without asking the browsing user to first log in to Facebook?
I can retrieve the latest status update of a Web page from client-side without asking the browsing user to first log in to Facebook
You cant do that without login.
And I guess access token is not exposed.
Maybe the smart trick here is to use a social plugin. The Like Box will do what you want, without any issues. But, it's not greatly customizable. Even so, it's possible to get it looking nice on a page!
It also skips any login issues you mentioned.
I found the answer after some Googling. In short, the answer is no.
And here's an excerpt from Facebook:
Security Best Practices
App Secret and App Access Token
The App Secret is used in some of the Login flows to generate access tokens and the Secret itself is intended to secure usage of your App to only those that are trusted. The secret can be used to easily create an App Access Token which can make API requests on behalf of any user of the app, which makes it extremely important that an App Secret is not compromised.
Therefore the App Secret or an App Access token should never be included in any code that could be accessed by anyone other than a developer of the app. This applies to all methods of code that are not secured like client-side code (such as HTML or Javascript) or native apps (such as iOS, Android or Windows desktop apps) that could be decompiled.
We recommend that App Access Tokens should only be used directly from your app's servers in order to provide the best security. For native apps, we suggest that the app communicates with your own server and the server then makes the API requests to Facebook using the App Access Token. For this reason, if your 'App Type' under Advanced Settings in the App Dashboard is set to Native/Desktop we assume that your native app contains the App Secret or an App Access Token in the binary, and we do not allow calls signed with an App Access Token to proceed. The API will behave as though no access token was provided.
If your App Secret is compromised, you should reset it immediately in the Basic Settings of your App Dashboard.
Can the Stack Overflow community sanity-check this for me?
I am working on a project that involves two components: an iOS app and a mobile website. It's for a product that will interact pretty heavily with Facebook. The website is hosted on Heroku.
From iOS land, my intention is to use the Facebook iOS SDK for authentication and then hit the web API with the user's access token at https://[myappname].herokuapp.com. Since Heroku offers piggyback SSL when using the herokuapp.com domain, and the user won't be seeing this URL anyway, I figure that's fine. And this way the request is encrypted, so the access token should be safe.
From the mobile website, users will log in using Facebook, at which point my understanding is that the access token will be in their cookies, which my server can then access without having to exchange it back and forth with each request. By this reasoning it seems to me I can just stick with regular unencrypted http:// URLs for the website (and therefore use my custom domain name without having to pay a monthly fee for Heroku's SSL Endpoint add-on).
Does this all make sense? I will be the first to admit my understanding of a lot of this stuff is in serious need of an upgrade. But for now I'm just looking for someone who can tell me, "No, you're totally overlooking/misunderstanding XYZ" or "Yeah, this is how it's generally done."
Facebook advises that you should not take a dependency on their cookie format. They have stated that the cookies are "an implementation detail" that they may tweak at any time with no notice given. You should not directly access the token or other user info directly from the cookie. I personally have had some bad experiences trying to get user information directly from the cookies, mostly due to timing -- they were not always there or updated when I expected them to be.
Client-side, you should either get the access token from the Javascript SDK via FB.getLoginStatus or other method that returns the access token, and then post it up to your server. This should really be done using ssl otherwise you are susceptible to network packet sniffing where a black hat could grab the token and be able to use all of the privileges the user granted your app.
There is also a server-side option as well which hits at ssl endpoint on Facebook's servers to return an access token.
References:
"Cookies are an implementation detail": https://developers.facebook.com/blog/post/624/
Authentication docs: https://developers.facebook.com/docs/authentication/
Website login via Facebook works totally fine via HTTP.
I need to post message on a certain FB page as a owner by cron, using php and ZF 1.1.X. For this small issue, I don't want to create a full OAuth stack. Is it possible to communicate with FB API (it's desirable, PHP SDK for FB) without it, such as twitter with his precreated access tokens (Access token, Access token secret)?
As long as you need an active user access_token to retrieve desired data this is not possible to skip OAuth flow.
Without authenticating user you only have application access_token (in old format APP_ID|APP_SECRET, but it's still works) and only limited access to most of Graph API endpoints and Application settings.
Actually there is nothing hard in implementing the user authentication with OAuth flow and it is completely transparent with usage of PHP-SDK.
Just look at the sample code in documentation for server-side authentication
Yes, you need to build an app and then authorize the page via the app while requesting the manage_page permission.
You should make yourself familiar with the Server Side Auth process as well.
TL;DR version:
Can you authenticate with Facebook without having a callback URL for a web application since the web application isn't actually running on a server.
Full explanation:
I'm working on building a connectedTV platform application where the "app" itself is a bunch of HTML/JS/CSS running locally (like File -> Open on your desktop browser) and I'd like to integrate Facebook into this.
The problem is that all of Facebook's OAuth calls for the web require you to have a callback URL to redirect the user to in order to complete authentication. Here's the gotcha -- there is no URL for this application -- it's a locally running webpage on the device.
I know this is what out-of-band authentication was designed for, but I can't seem to find any documentation on how to use this (or how to do a non-callback OAuth flow) with the Facebook OAuth system.
You're describing desktop authentication or any situation where you are authenticating to FB without a server. The redirect URL you pass to the OAuth dialog is https://www.facebook.com/connect/login_success.html When the browser redirects you can get the access token. You can read all about it in the FB documentation, way at the bottom in the Desktop Apps section (https://developers.facebook.com/docs/authentication/)
Just reread your question and since the application runs inside a browser you will need to open another window to authenticate and get the access token from that.
If you're doing HTML/Javascript, use their Javascript SDK. You can log the guy in simply by using FB.login and getting the access token from the callback from that.
I really don't think this is directly possible. Unless there is something totally undocumented, Facebook has no mechanism to send authentication data except by loading a url. I'm sure it's meant at least partly as a security measure, functioning as sort of a "whitelist" of where auth data will be sent.
The only way I can think of for you to work around it might be to set up a url on a server somewhere that could answer the redirect and store the auth data, and have your client-side code poll that server to get it. Kind of a proxy authentication service, in effect. You would probably have to open a second browser window with the Facebook auth screen in it, but in theory it could work.
I have a website based game that has login accounts that I want to integrate into facebook (not facebook connect, I want to use an iframe canvas page).
My question is how can I authenticate a user and how can I check if a user is coming from facebook or directly from the site.
I have been playing around with require_login() using the PHP library. My main fear is how can I authenticate that the GET parameters from facebook are indeed from facebook? If I can do that then I can store their facebook session id and Uid in a session as login credentials.
My other worry is that the GET variable may get passed as a reffer to an external link.
Finally... I find in some browsers that with require_login() that it breaks out of the iframe and gets into an eternal look continually adding additional authtoken's to the URL.
Hope someone can help
Yes you can create a app that works independently as well as facebook app. For the facebook you will have to use the facebook's iframe method to work under facebook.
You can verify the request comes from Facebook by verifying the signature in the same way that Facebook checks that API requests come from your application. With the PHP client library you can use the validate_fb_params() method of the Facebook class to do this automatically.
Bear in mind that session key's are temporary so the user will keep needing to authenticate with Facebook through your application otherwise the key expires within the hour. You may also run into a 3rd party cookie issue with Safari if you're hoping to store the session key in a cookie, and you'll need a compact privacy for quite a few other browser/privacy setting combinations as well. Something like:
<?php
header('P3P: CP="CAO PSA OUR"');
?>
in an include would do it.
And yes: the session key may be passed to external sites as in the referrer properties. It's just one of the security flaws that the platform currently has. The only way around that is either to redirect all external clicks through a handler which removes the referrer, or redirect on page load to strip the fb_sig_ss parameter out.