The Facebook documentation says that since October 1, 2011 canvas apps must provide access over HTTPS. Is the opposite true? Must canvas apps provide access over HTTP? I'd rather have my app accessible through HTTPS only. Will Facebook users using HTTP be able to use my app if I don't provide a non-secure endpoint?
If you only specify a secure URLK - they will not be. They will be prompted with a layer asking them to enable secure browsing. They will NOT be able to access you application.
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.
If you have the Save Surfing setting in your account settings in Facebook set to unsecured, you notice you use Facebook via HTTP. Of course if you set it to On, you surf via HTTPS.
Now all Facebook apps are using HTTPS since Facebook doesn't allow apps to use HTTP since October 2011. But if a user (with no HTTPS on their Facebook account) wants to visit the Secured HTTPS App it just gives an empty page.
Is this a bug from Facebook, or?
Now all Facebook apps are using HTTPS since Facebook doesnt allow apps to use HTTP since October 2011.
That’s not true.
All canvas/page tab apps must offer the option to be accessed via HTTPS – but should offer HTTP as well.
But if a user (with no HTTPS on there Facebook account) wants to visit the Secured HTTPS App it just gives an empty page. Is this a bug from Facebook, or?
No, this is an error on your (resp. the app developers) part – in the app settings, there should be URLs set for both HTTP and HTTPS.
If that’s the case, then a user browsing Facebook via HTTP has no problem accessing the app as well.
I have an app that only runs on https. So my Pag Tab URL and Secured Page Tab URL have the same https url.
I have noticed that I get a blank signed request for users who are using Facebook on http.
Is there a way by which I can get the users to see my secured content even when they are accessing facebook from http?
Facebook says that this configuration is not supported by design. Apps must be available via both HTTP and HTTPS.
Source: http://developers.facebook.com/bugs/210713629051920/
Unfortunately it is necessary you always provide a HTTP alternative
for FB users who want to visit your App under HTTP. In your specific
case, in your http endpoint you will be able to display an specific
message to these users encouraging them to visit the HTTPS version of
your App.
My site allows users to login through facebook coonect. Do I need to support ssl on my site by Oct 1?
Will greatly appreciate your input.
Thanks,
cody
IF you conform to the following sentence, you must support SSL by Oct 1st:
an SSL Certificate is required for all Canvas and Page Tab apps
See https://developers.facebook.com/docs/oauth2-https-migration/ for more details.
It seems like if you are not using Canvas or Page Tab ON FB, then SSL won't be required on your site for FB Connect. You will have to make the api call to FB over SSL and must config your app to use OAuth 2 -- for the JS SDK that means setting oauth:true. See https://developers.facebook.com/docs/oauth2-https-migration/
Only on *.facebook.com are you required to use an SSL certificate. More specifically, you must specify a URL that begins with https:// for your canvas URL as of Oct. 1st. When https://apps.facebook.com/<YOUR_URL> or https://www.facebook.com/<YOUR_URL> loads your IFRAME, the IFRAME url must begin with https.
However, you do not need to support SSL on your website outside of Facebook. If you use Facebook for Websites, you need to make no change to that portion of your Facebook implementation.
The idea is that one day all traffic on facebook.com will be https by default, and they don't want mixed content warnings when https://*.facebook.com loads up your IFRAME url.
I am using the new javascript sdk and I am developing locally (ie. no hosted server).
I was successfully able to get the access token which the js api stores in a cookie for localhost domain. However what I don't understand is:
How fb js is able to set a cookie for localhost. Doesn't this violate same origin policy?
If fb uses Oauth 2.0 protocol for authentication/authorization, how is the single sign-on able to retrieve the access token even when though I haven't specified a callback url and there are no redirect from my main page.
Can someone demystify what is happening under the hood here?
FB JS is able to set cookies on localhost because you're including the FB JS SDK on your domain via a <script> tag there by giving them access to your cookies (much the same way Google Analytics writes cookies for your domain).
OAuth 2.0 involves a redirect to your website, there's really no other way for Facebook to return the code necessary for your app to retrieve the access_token.