Facebook 是否更改了测试用户帐户的系统？
这可能是我从文档中进行的推断（考虑到文档的组织方式，这并不是太难），但是 Facebook 是否对应用程序开发人员创建和利用测试用户的方式做出了一些重大改变？
据我回忆（我上次这样做是在大约一个月前），开发人员过去可以从登录帐户内访问一个网址，将该用户转换为“测试用户”，而该用户在公共场合没有任何权限。系统，但可以作为发布、获取权限等的测试实体。我通过此方法设置了一个测试用户，并为他/她生成了访问令牌，并将其保存到数据库中。
最近这一切都停止了。我的第一个本能是打印出我创建的 Facebook 对象的属性，一旦有 JSON 解码的用户数据，现在访问 /me/ api 端点的 CURL 进程出现异常。
Facebook GraphAPI – 未捕获 EntCannotSeeExistenceException：当前查看者 12345 无法看到 id 12345 支持的实体（类 EntTestUser）（EntID：12345）
值显然已更改以保护无辜者。然而，用户 ID 是相同的，这让奇怪的是，由于某种原因拥有 ID 12345 的用户无权查看 12345
我查看了 Facebook 文档，发现他们的新逻辑似乎是让应用程序本身创建临时测试用户并为他们生成登录 URL，这里的很多人可能都熟悉这一点。
http://developers.facebook.com/blog/post/429
此系统已被取代旧的？似乎不再允许代表通过旧方法生成的测试用户帐户进行操作，因为它们不是“由”应用程序创建的。我编写了一些快速逻辑来使用固定访问令牌测试这个新流程，并且它有效 - 我还应该提到，所有应用程序逻辑功能都与最初一样，对于真实用户帐户没有错误。有其他人在使用 Facebook api 应用程序时遇到过这种情况吗？我们是否可以肯定地说，通过旧方法创建的这些旧访问令牌/用户 ID/帐户现在实际上毫无用处？
一如既往地感谢。
This could be me making extrapolations from the documentation (which given how it's organized, isn't too difficult to do) but did Facebook make some big changes to how application developers create and utilize test users?
To my recollection (and I last did this about a month ago), developers used to be able to go to a url from within a logged in account that would convert that user to a 'test user', who had no privileges in the public system but could serve as a test entity for publishing, getting permissions, etc. I had a test user setup via this method and had generated access tokens for him/her that were saved to the database.
Recently this all stopped working. My first instict was to print out the properties of the Facebook object I had created, and where once there had been the JSON decoded user data, there now was an exception from the CURL process that accessed the /me/ api endpoint.
Facebook GraphAPI – Uncaught EntCannotSeeExistenceException: The entity (class EntTestUser) backed by id 12345 cannot be seen by the current viewer 12345 (EntID: 12345)
Values obviously changed to protect the innocent. The userids were identical however, which made it strange that the user possessing ID 12345 for some reason had no rights to see 12345
I looked through the Facebook documentation and found their what seems to be their new logic for making the application itself create temporary test users and generate login URLs for them, something alot of people here are probably familiar with.
http://developers.facebook.com/blog/post/429
Has this system superceded the old one? It seems that acting on behalf of test user accounts generated via the old method is no longer permitted since they are not made "by" the application. I wrote some quick logic to test this new process with fixed access tokens and it worked - I should also mention that all the application logic functions as it originally did with no errors for real user accounts. Has anyone else experienced this with their Facebook api apps? Can we definitely say that these old access tokens/userids/accounts made via that old method are now effectively useless?
Thanks as ever.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
http://developers.facebook.com/blog/post/475
我讨厌破坏形成并回答我自己的问题，但从评论来看，似乎有足够多的人遇到这个问题。
今天深入研究开发人员更新，我终于找到了上面的帖子（当然已经写了解决方法）引用：
这个小通知与三月份的更新混合在一起。也许应该 RSS 他们的开发者博客，这样这些事情就不会再让我感到惊讶了！此特定更新于 3 月 4 日生效。无论如何，从源头上得到一个结论性的答案是件好事。
http://developers.facebook.com/blog/post/475
I hate to break form and answer my own question, but from the comments enough people seem to be having this problem.
Digging through the developer updates today I finally found the above post (having already written workarounds, of course) Quoted:
This tiny notification was mixed in with the updates for March. Probably should RSS their developer blog so these things don't take me by suprise again! This particular update became effective March 4th. In any event, it's good to have a conclusive answer right from the source.