My application is running within an IFrame and has been running fine for month. Since last week, the main page keeps refreshing because it looks lie the parameters auth_token and fb_sig_session_key are not provided to my iframe content anymore.
Has anything changed on the platform lately with that regard ?
Many thanks for your support.
Jonathan.
According to the Facebook Signed Request, you are only provided oauth_tokenalong with some other data, but nothing that looks like fb_sig_session_key. Try looking through the tutorial on the signed request, as well as the other authorization tutorials on Facebook. They provide the most up to date information.
If you are still using the Legacy Canvas Auth, you'll want to read the passage there about migrating. Instead of fb_sig_session_key, you should use Use the oauth_token for all API calls.
Related
I started to receive problems with sharing from LinkedIN last week. Prior to last week shares were working fine. When I try to share an article, their share program appears to go into a loop. The linkedIN share page comes up but it just spins and spins and spins.
This is the url – encoded url and encoded title.
https://www.linkedin.com/shareArticle?mini=true&url=http%3A%2F%2Fmydomain.com%2Fcs%2F24912%2F39%2Fnull%2F93538%2F&title=Is+There+Still+a+Place+for+Print+Marketing%3F
When I look in the developer tools on chrome it appears that the page is in some kind of loop. As it keeps loading the following share page over and over…
https://www.linkedin.com/sharing/share?url=http%3A%2F%2Fmydomain%2Ecom%2Fcs%2F24912%2F39%2Fnull%2F93538%2F&title=Is+There+Still+a+Place+for+Print+Marketing%3F&trk=LI_BADGE_OLD
So I do the exact same call, just change the url to google
And it works.
I also have an app that is behaving the same way – when I post using the app – with rw permissions, I get an internal service error if I use my domain but I can post successfully using google.
Any help would be greatly appreciated.
This problem was resolved. The domain was listed in SPAMHAUS DBL (incorrectly, but that's a subject for another day). De-listed it and things are back to normal. LINKEDIN It would be great to return the real error versus an internal server error. For anyone that runs into this problem, check SMAPHAUS DBL listing.
As you can see on the image, spotify has a modified version of facebook login.
On the spotify app shown, user can login using either facebook or spotify account.
I wonder if its only on the looks or they were using other facebook authentication process.
I also wonder and worried if spotify could get facebook password entered by the user.
What facebook authentication they were using in here?
As you have noticed, Spotify is using a different Facebook login flow that is not listed anywhere in the official Facebook developer documentation. Since the Facebook password is entered into a closed source client, there is no way for you to know for sure what happens without heavy reverse engineering and debugging of the client. In that sense you should be worried. It goes against and devalues the good policy of "Please don't enter your password anywhere else". Thinking about differently, Facebook trusts this company enough to allow this. There might be a few more companies that have the ability to use this login flow, but I don't know.
I work at Spotify and was there when it was introduced (September 2011). We worked very closely with Facebook (I helped build some parts of the backend integration). It is not my favorite part of the client though. I would much prefer a standard Facebook OAuth 2 authorization flow. That was however one of the main technical problems in spring 2011 when we started to build this. We basically needed to embed a browser in the client to make it work properly or redirect the user to a browser and then back to the client again. There were also other reasons that I can't remember why we didn't do this.
Now when we have an embedded browser (since December 2011) it would be much easier to change. I believe this type of login flow will be phased out eventually.
This is a first time I am trying to make a facebook application/game, and I have couple of questions.
Let's say canvas url is http://mysite/first_app/ and facebook app url is https://apps.facebook.com/first_app
I wonder if visited both url-s should a functionality be the same? I mean does facebook give you more tools and freedom if navigated from https://apps.facebook.com/first_app? Or should both url-s look and do the same thing? Is it possible?
I wonder if visited both urls should a functionality be the same
Of course yes. The difference is just that one is deployed at the facebook's app center and the other at your domain.
Yes, you have more tools available in the canvas ("apps.facebook.com.."), as it will send you the user-id without any user consent. Has the user previously used your app, you will also be able to get their accesstoken and fetch more info about them.
It requires some backend code to decode the signed request parameter, which provides you this stuff.
This example is how php handles signed request:
https://developers.facebook.com/docs/facebook-login/using-login-with-games/
If you're using C#, download the Facebook C# (available through NuGet, the package from Outercurve Foundation) and use this example:
How do I parse a signed request in Facebook C# SDK?
I try to handle the user in Facebook context whenever possible. It adds trust and more tools. Although since the Facebook phone/tablet app (App Store/Google Play) doesn't support Facebook apps at all, I often optimize the app for mobile web use also. I read somewhere that over 50% of daily Facebook visists are done using the phone app, so it might be something to think into your app while developing.
UPDATE:
I can see I have misunderstood part of signed request, as commented by Shadowfax and CBroe. In my app, I use the user id from signed request but of course only when the user has already logged on to the app beforehand. My apologies.
I just got this email from Facebook:
Dear Developer,
As part of our continued efforts to migrate all apps to OAuth 2.0, we
opted in all apps using the new JavaScript SDK to OAuth 2.0 this
afternoon at 11am PT and reverted at 1:30pm because we noticed that
your app has not migrated. Please ensure that you have set the oauth
param in FB.init to true and that you are using FB.getAuthResponse to
obtain the access token.
Read more in the OAuth2 migration announcement, updates to the new JS
SDK blog post, or our JS SDK docs.
If your app was affected today, please ensure that you have made these
changes by December 13th, 2012 to avoid any disruption with your
users.
The email doesn't specify which app needs my attention, and I can't make heads or tails of it.
Can anyone tell me what I need to be doing here? I have seven apps:
Four were created solely because I needed an app ID (API key) to install the "Like" button on various sites. Do I need to add "oauth: true" to the FB.init() call on these pages? (None of them actually integrate with Facebook authentication. All they do is render Like/Send buttons, and hook into the Edge.create callback for tracking purposes.)
Two of my apps are just tabs that I've added to Facebook Pages, which pull in static HTML pages (hosted elsewhere) via iframe. There's no JavaScript or server-side code whatsoever. I presume I can leave these alone?
One is an off-the-shelf app from a third-party provider. Looking at their code, I see that their call to FB.init() already includes oauth: true.
Facebook does a really terrible job with developer documentation, explaining changes, and maintaining backward compatibility. I'm a pretty experienced developer, but it seems like you have to learn every nook and cranny of Facebook's (ever-changing and over-complicated) proprietary API suite just to use the simplest features. I'm not a Facebook app developer (and I don't want to become one); I'm just a guy who wants to use a few "Like" buttons and custom page tabs, preferably without having to wade through this nonsense every two months when Facebook decides to change everything around and break backward compatibility again.
Anyway, any guidance would be much appreciated!
If you didn't see any of the blog posts since May - here's a summary: https://developers.facebook.com/docs/oauth2-https-migration/
To answer your specific questions, the 4 apps used only for the social plugins don't really USE oauth - but adding the oauth:true param and making sure they still work shouldn't be a huge issue - it also explicitly indicates to facebook that you're using the new auth mechanisms on those app IDs, so you shouldn't have an email sent about those apps in future
If your other apps aren't actually using any authentication, you probably don't need to do anything - if there was a problem you'd have discovered it yesterday when the oauth migration was flipped on for apps - the non compliant apps would have ceased working correctly
For a middleware system with internet (which works inside a set-top box) I want to develop a primitive Facebook interface where users can type their user-names and password, showing their latest notification, messages and other casual stuff on the TV screen by using the recent Facebook Graph API.
This middleware program uses Java ME to run programs (such as this simple facebook app) and it can connect to internet however it doesn't have a real web browser. Without browser it can connect to any url to retrieve the JSON response however I am not sure how to achieve authentication without a real browser.
Under this circumstances, is it possible Facebook authentication? If you think so, what approach would you suggest ?
Thanks
Facebook provides trusted partners with a private Authorization API to get an OAuth 2 token from a username / password.
A more complicated approach would be doing something similar to how Netflix enrolls a device:
device calls server to obtain a Code
device shows code on screen and directs user to go to URL on server and enter Code
server redirects user to Facebook and obtains OAuth token, user told to go back to device
device calls server with Code and obtains OAuth token
device can now make calls directly on behalf of user
According to this documentation on "Desktop Application Authentication" I don't believe your desired result is possible:
Facebook's OAuth implementation does not include explicit desktop application support. However, if your desktop application can embed a Web browser, you can add Facebook support to your application easily using the same OAuth User-Agent Flow used by JavaScript clients.
However, it is clearly possible for certain vendors to do this, since Microsoft's Xbox 360 Facebook application does exactly what you are proposing. I'd be interested to see if anyone has dug up any API for doing this that Facebook doesn't want in their most obvious documentation.
This isn't an answer but I'm trying to do the same thing. Check out this guy's blog which uses another server to proxy the requests:
cory wiles blog
If you figure it out please post a detailed answer here so I can do it to.. :)
I think it is possible though it is pretty complicated and subject to sudden changes of Facebook interface. It might break the agreement between you and Facebook.
What you do is to emulate the Facebook.
One path you have to set up a Facebook application. Once you got the authorisation from user, you can to something with Graph API.
You need to the Facebook log-in process and authorisation process. There are some capturing tools on http/https request and response. Analyse them, both header and body.
Once you know the authorisation mechanism, you can replace it with you own. Everything afterward is on Graph API.
Another path is to emulate Facebook login and message and notification process. Capturing and analysis is needed.
In the past I have used a tool called screen-scraper (full disclosure: I used to work there) to automate logging in to facebook. Basically, it imitates a browser session; it allows you to set session variables (i.e. username, password) which would then be submitted to facebook, just as if the user had submitted them in a browser.
You may not be able to use screen-scraper in your set-top box environment (although it is java-based, so it's possible it would work). Even if it doesn't, you could implement a similar strategy in java, making the HTTP calls a browser would make to load the login page and submit the user's credentials. To keep the user's info safe make sure whatever HTTP client library you use supports HTTPS.
Proxy tools and extensions like Charles, Fiddler2, Firebug, Chrome's dev tools, etc. are helpful in seeing exactly what the browser is sending to the server in requests.