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!
Related
I know this is a relatively open-ended question, but since facebook doesn't have any specific developer support forums themselves, I'm wondering if anyone has any advice here --
I'm building an app that uses a pre-authenticated proxy server to pull public page/page-event data from a predefined set of pages. Since there will be no need for a user login (or there will be just a single personal account's auth token tied to the proxy), I'm having a hard time wrapping my head around how to go about writing a privacy policy (requirement now for apps).
I know I need Page Public Content Access but the legal-speak required for a privacy policy about how to handle users' data and so on is tripping me up, since I won't be collecting any. It's actually an important part of the app that no login is required.
My question specifically being: a request for resources that can aid me in writing a privacy policy that will be approved, for a scenario that users' data is not actually ever supposed to be a part of the app.
Help, please, thank you!
We are integrating an application as a facebook app at work. I want to be able to detect whether the user has logged in to facebook, and if not, to prompt for authentication.
So far we have successfully used the facebook SDK and the login functionality it provided. However, this causes an authentication popup window to be created by our application, and it is being blocked by most of the browsers, so our priority task is to re-implement the authentication logic not to use popups.
According to the this tutorial from the facebook documentation it could be done either by using event subscription for user status change requests (which did not work when the user is logged out) or by obtaining access token. The problem is that the token is returned as request parameter to the top window (the url I specify as a return url after the user authenticates). Since some cross-domain and browser restrictions exist, I am unable to use client scripting to obtain the value, and I am stuck.
Related questions here have been asked and the common issue is that most apps are being ran on localhost. However, the case with our app is that we have deployed our app to local webserver, that is exposed by a public domain, but still has the cross-domain restriction issues. It is being referenced by its public domain name within the facebook app configuration. I am completely confident in that the domains are fully accessible from outside.
In general, our case is that we would like to host the app while it is being used by facebook users. Perhaps this approach might be incompatible with our requirement? Is it possible to configure cross-domain communication to avoid the issue? Are any other ways to do avoid facebook login popups?
First of all, default settings for popup blockers in modern browsers are so that they only block popups that are called without user interaction. If you call FB.login automatically on page load, it is likely to get blocked. But if you offer a link/button to the user saying “log in here” and only call FB.login on click on that link/button, then the popup is rather likely to be shown and not blocked.
If you are not willing to do it that way – then your other option is to use the server-side auth flow. You can just redirect the user to the auth dialog, which will happen in the same window, and he will be directed back to your app afterwards.
I'm writing a Windows Phone 7 app and have gotten Facebook login working using the C# sdk, but logging out has proven interesting. I've read this post:
Cannot Logout of Facebook with Facebook C# SDK
which seems to mirror the FB docs which indicate I should navigate to
https://www.facebook.com/logout.php?next=[redirect_uri]&access_token=[token]
However, that doesn't work and silently redirects me back to the facebook home page.
My best guess at the moment is facebook doesn't like the "next" URI I'm providing. I updated my FB app settings but either they haven't propagated yet, or something else is still not working.
I've seen posts recommending using InternetSetOption, but that API is not available on the phone.
In my application flow, logout leads to navigating to a different silverlight page in my app, so I really don't need the browser redirect for my purpose anyway, so I could just "forget" the access token without actually telling FB to invalidate it, but that seems weak and insecure.
So, while I wait longer to see if the app domain changes propagate across FB's servers and solve the problem I have a different question:
Why should the Facebook APIs care whether I provide "next" or not? Shouldn't I just be able to tell them to invalidate a token and have it happen?
Is there a logic piece I'm missing here?
Thanks!
Update: I wrote an open-source Facebook login/logout control for WP7 that allows this (check the example project). It works by essentially using the web browser control to navigate to the logout page and then submit the logout form by injecting javascript into the web browser control. The idea came from this blog post.
The closest thing would be to revoke the extended permissions by issuing an HTTP DELETE to /me/permissions as documented here. Simply forgetting the auth token isn't a bad option either as the access tokens are generally only good for an hour or two unless you asked for offline_access. And if a user is overly concerned, they can remove your application on their settings page on facebook.com.
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 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.