如何避免将用户信息从 Facebook Connect 应用泄露给 AdSense
我有一个 Facebook Connect 应用程序，可以使用 Google AdSense 获利。我想确保我不会泄露任何 Facebook 用户信息，例如 Facebook 用户 ID 号或访问令牌（其中包含用户 ID）。
AdSense 完全合法，并且符合 Facebook Connect 应用程序的政策。我只需要确保 Google 无法看到识别用户身份的信息。
当我设计我的应用程序时，我很清楚这些要求，并认为我已经把它钉牢了，但后来我收到了一封来自 Facebook 的著名自动警告电子邮件，其中写道：
“我们的自动化系统检测到您可能无意中允许身份验证数据传递给第 3 方。”
它还指出：
“在我们检查过的每种情况下，此信息都是由用户浏览器通过 HTTP Referer 标头传递的。”
同样，我已经熟悉了这种泄漏向量，当 Facebook 在用户身份验证后重定向回您的应用程序时将访问令牌放入查询字符串时，就会发生这种情况。我已经有了一个设计，通过服务器端 OAuth 2.0 重定向来处理此问题，获取“代码”并将其交换为访问令牌。此方法在服务器端身份验证下进行了描述： https://developers.facebook.com/docs/ 在我的应用程序
中，我在没有视图的单独 ASP.NET MVC 控制器中进行代码令牌交换，因此不包含 Adsense 或任何第三方资源。因此，我确信我的所有标头引用字段内容和查询字符串都是干净的并且不包含用户数据。
然而，鉴于我收到了来自 Facebook 的电子邮件通知，并且不希望我的应用程序和 AdSense 资金水龙头关闭，我现在怀疑我在其他地方泄露了数据。话又说回来，电子邮件说我的应用程序“可能”泄漏信息（为什么哦为什么他们不能告诉我他们看到了什么，或者至少确定它正在泄漏，而不仅仅是“可能”泄漏），而且它说每个实例都是由于引用/查询字符串造成的，我再次确信（完成了 Fiddler 跟踪）我的应用程序是干净的。
我只看到信息可能泄露的一种可能方式，但我不确定这是否是真正的风险，或者只是我对 AdSense（和 Google Analytics）可以从我的应用程序内容中看到的内容缺乏了解。要求用户进行身份验证的页面。
我有一个视图（页面），我将访问令牌放入隐藏的表单字段中。它在页面最初提供时（在用户经过身份验证后）放置在那里，然后通过 Javascript 进行更新（使用 Facebook JS SDK），因此当用户将表单发回服务器时，我会得到更新的 access_token如果它改变了。访问令牌可能会更改，因为我使用 Javascript SDK 提示该页面上的其他权限，包括在某些情况下的 Offline_access 扩展权限。获取offline_access会生成一个新的access_token，并且不会过期。
这是一个需要用户经过身份验证才能查看的页面，因此我认为 AdSense 无法看到该页面内容。如果用户未经过身份验证，我确实有视图设置以通用方式（无用户信息）呈现所有相同的文本，但添加了“立即登录”提示，因此 Adsense 可以索引页面并提供相关的上下文广告。
我知道 Facebook 昨天刚刚推出了新的 OAuth 2.0 Javascript SDK 功能，但无法立即采用，因为它无法与我在服务器端使用的 Facebook C# SDK 配合使用。即使如此，如果我在将访问令牌放入隐藏表单字段时遇到问题，该问题仍然存在。
按照 Facebook 的经典做法，他们给了我 48 小时的时间来解决问题，但通过他们的开发人员支持网络表单进行的任何询问只会得到这样的答复：他们将“尽最大努力在一周内回复您的具体问题”。
也许思考这个问题的一个更简单的方法是“Google AdSense 能否看到需要用户身份验证的页面的页面内容？”或者他们是否只看到加载 AdSense javascript 文件的标头引用字段。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在不知道您的代码详细信息的情况下，也很难准确说出他们检测到的内容 - 但我猜测可能实际上确实泄漏了信息。他们会识别出他们知道会泄漏的特定模式，并且他们发现该模式存在于您的应用程序中
为什么不设置一个代理服务器（例如鱿鱼），然后将您的浏览器指向所有http的鱿鱼实例使用权。然后，您可以查看所有 http 请求和标头的鱿鱼日志，以了解可能泄漏的内容？
我认为你应该选择一台独立的机器来安装鱿鱼，所以如果你还没有可用的机器，亚马逊微型实例可能就是你所需要的此外
，页面上运行的所有 JavaScript 都可以看到 DOM 中的所有内容，并且所有全局 JavaScript 变量，因此如果您/Facebook 担心以这种方式泄漏信息，您可能希望将所有 uid 存储在闭包内和/或在 iframe 中而不是直接在页面中运行 adsense 代码 - 作为一般的疏忽规则，您应该绝不允许第 3 方 JavaScript在您的页面中运行的代码，而无需将其包装在 iframe 中
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
他们对我的网站进行手动审查后回复我，并表示它实际上并未泄露任何用户信息。感谢 Facebook 的自动检测系统！
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!