应用错误收集

<context>我昨天感到沮丧并发布了一个火焰问题，很快（并且适当地）关闭并被我的同伴SO队列删除。雅虎关闭其标准的PlaceFinder API端点并将其替换为付费服务。这不是让我感到沮丧的部分，但主要是因为他们改变了他们的访问模式以要求OAuth。我的问题的一个关闭者评论了一些影响：

你没有密切关注你所依赖的API的弃用，OAuth 对用户来说更好，吸收它。

虽然我可以通过再次指责雅虎在去年10月/ 11月首次宣布API弃用时断言链接，但我认为看看我的API观看的事实，我认为尝试转换它会更有成效进入一个聪明的问题。 </context>

我使用过OAuth。我喜欢OAuth。它不仅可以让您对用户进行身份验证并简化应用程序的登录，还可以让您请求授权从其他应用程序访问该用户的数据。但PlaceFinder数据不是私人用户数据。它适用于所有人都可以共享的已知地名和全局标识符（WOE ID）。

今天早上我给了雅虎！ BOSS GEO我的信用卡信息，并开始哄骗OAuth API消费者进行测试。我从DotNetOpenAuth开始，我过去曾使用过OAuth guide。我通过Yahoo！的DotNetOpenAuth阅读并使用所有Yahoo！OAuth 6.1,6.2和6.3端点URL创建了一个DotNetOpenAuth.OAuth.ServiceProviderDescription实例。然后我试着弄清楚如何使用DotNetOpenAuth.OAuth.WebConsumer来点击PlaceFinder API并开始向雅虎捐款！

但它没有用。我必须克服许多认知失调，最终要么限制流行的和广泛使用的BOSS documentation库本身，要么可能滥用OAuth。当我终于意识到BOSS GEO documentation与C# code sample that worked to consume Yahoo!'s PlaceFinder API分开，并找到DotNetOpenAuth时，我发现了所有这种不和谐的来源。

雅虎的PlaceFinder API虽然使用OAuth，但不需要访问令牌来获取API的端点或数据。当您发送PlaceFinder请求时，您将所有应用程序的信息（使用者密钥和密钥）以及时间戳，随机数和签名发送到PlaceFinder端点本身。当我过去使用OAuth时，这些元素被发送到6.1端点以获取请求令牌。然后，您可以使用它来验证/授权用户（6.2）并获取访问令牌（6.3）以进一步请求。

这是sample C# code on Yahoo!'s site到目前为止我无法克服的限制，所以如果我无知并且做错了，请告诉我。在{{3}}中，他们没有使用DotNetOpenAuth。相反，他们有一个OAuthBase类，您可以使用它来生成随机数，时间戳和签名。但是他们为访问令牌和秘密发送空字符串。我尝试使用DotNetOpenAuth，但它不会让你使用null或空访问令牌构造任何请求。

所以问题：这是否适用于OAuth标准？如果没有，DotNetOpenAuth库中是否存在限制，使得无法将未经授权的请求发送到除RequestToken（6.1）之外的端点？如果这两个问题的答案都是否定的，那么如何使用DotNetOpenAuth来请求PlaceFinder数据而无需发送访问令牌或秘密？

这是一个很好的问题。我认为oAuth为BOSS开发者提供了两个好处

由于您只需注册一次BOSS，然后可以将该密钥用于多种服务，BOSS团队希望能够灵活地提供将来需要令牌的更多服务。从开始就开始使用oAuth允许灵活性。
团队希望确保在网络通信期间不会嗅出密钥。由于请求已签名且实际密钥未通过，因此我们可以确保不会发生嗅探。

关于你关于DotNetOpenAuth的问题，我建议询问BOSS Y！ group（http://tech.groups.yahoo.com/group/ysearchboss/）因为我们有很多用C＃编写的人，VB.Net可以为你提供建议。事实上，众所周知，VB.Net oAuth库（http://oauth.googlecode.com/svn/code/vbnet/oAuth.vb）存在一些问题。

是雅虎！ PlaceFinder适用于OAuth的用例？

2 个答案: