<context>我昨天很沮丧，并发布了一个火焰问题，该问题很快（并且适当地）被我的 SO 同伙关闭并删除。雅虎！关闭了其标准 PlaceFinder API 端点并用付费服务取而代之。不过，这并不是让我感到沮丧的部分，主要是因为他们将访问模型更改为需要 OAuth。我的问题的关闭者之一评论了一些内容：
你没有关注你所依赖的 API 的弃用，OAuth 对用户来说更好，接受吧。
虽然我可以通过再次指责雅虎在去年 10 月 / 11 月首次宣布弃用 API 时破坏链接来争论我的 API 观看的事实，但我认为尝试将其变成智能的会更有成效问题。</context>
我使用过 OAuth。我喜欢 OAuth。它不仅可以让您验证用户身份并简化应用程序的登录，还可以让您请求授权以从其他应用程序访问该用户的数据。但 PlaceFinder 数据不是私人用户数据。它适用于每个人都可以共享的已知地名和全球标识符 (WOE ID)。
今天早上我给了雅虎！BOSS GEO 我的信用卡信息，并开始使用 OAuth API 消费者进行测试。我从过去使用过的DotNetOpenAuth开始。我通读了 Yahoo! 的OAuth 指南DotNetOpenAuth.OAuth.ServiceProviderDescription，并使用 Yahoo! 的所有 OAuth 6.1、6.2 和 6.3 端点 URL创建了一个实例。然后我开始尝试弄清楚如何使用DotNetOpenAuth.OAuth.WebConsumerPlaceFinder API 并开始向 Yahoo! 捐款。
但它没有用。我必须克服许多认知失调，最后，要么是流行且广泛使用的DotNetOpenAuth库本身的限制，要么是 OAuth 的可能滥用。当我终于意识到BOSS 文档与BOSS GEO 文档是分开的，并找到了一个可以使用 Yahoo! 的 PlaceFinder API 的 C# 代码示例时，我发现了所有这些不和谐的来源。
Yahoo! 的 PlaceFinder API 虽然使用 OAuth，但不需要访问令牌即可获取 API 的端点或数据。当您发送 PlaceFinder 请求时，您会将应用程序的所有信息（消费者密钥和秘密）以及时间戳、随机数和签名发送到 PlaceFinder 端点本身。当我过去使用 OAuth 时，这些元素被发送到 6.1 端点以获取请求令牌。然后，您可以使用它来验证/授权用户 (6.2) 并获取访问令牌 (6.3) 以发出进一步的请求。
这是迄今为止我无法克服的DotNetOpenAuth限制，所以如果我无知并且在这里做错了，请告诉我。在Yahoo! 网站上的示例 C# 代码中，他们没有使用 DotNetOpenAuth。相反，它们有一个OAuthBase类，您可以使用它来生成随机数、时间戳和签名。但是他们为 access token 和 secret 发送空字符串。我尝试使用 DotNetOpenAuth 执行此操作，但它不允许您使用 null 或空访问令牌构造任何请求。
那么问题来了：这是对 OAuth 标准的不当使用吗？如果没有，DotNetOpenAuth 库中是否存在限制，使得无法向 RequestToken (6.1) 以外的端点发送未经授权的请求？如果这两个问题的答案是否定的，您如何使用 DotNetOpenAuth 来请求 PlaceFinder 数据而无需发送访问令牌或密码？