<context>私は昨日イライラして、すぐに (そして適切に) クローズされ、仲間の SO コホートによって削除された炎の質問を投稿しました。ヤフー！標準の PlaceFinder API エンドポイントをオフにして、有料サービスに置き換えました。それは私を苛立たせた部分ではありませんが、OAuth を要求するようにアクセス モデルを変更したという事実がほとんどでした。私の質問のクローザーの1人は、次のようなコメントをしました。
依存している API の非推奨に注意を払っていませんでした。OAuth はユーザーにとってより優れています。
昨年の 10 月または 11 月に API の廃止を最初に発表したときに Yahoo がリンク切れを起こしたことを再び非難することで、API ウォッチングの事実を主張することはできますが、これをインテリジェントな質問。</context>
OAuth を使用しました。私は OAuth が好きです。ユーザーを認証してアプリケーションへのサインオンを簡素化できるだけでなく、他のアプリからそのユーザーのデータにアクセスするための承認を求めることができます。ただし、PlaceFinder データはプライベート ユーザー データではありません。これは、既知の地名とグローバル識別子 (WOE ID) のためのもので、誰でも共有できます。
今朝、Yahoo! BOSS GEO でクレジット カード情報を取得し、OAuth API コンシューマーをテストするためにスパイクを開始しました。過去に使用したDotNetOpenAuthから始めました。Yahoo! のOAuth ガイドを読み、Yahoo! のDotNetOpenAuth.OAuth.ServiceProviderDescriptionOAuth 6.1、6.2、および 6.3 エンドポイント URL をすべて使用してインスタンスを作成しました。DotNetOpenAuth.OAuth.WebConsumer次に、PlaceFinder 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、ナンス、タイムスタンプ、および署名を生成するために使用できるクラスがあります。ただし、アクセス トークンとシークレットには空の文字列を送信します。DotNetOpenAuth でこれを実行しようとしましたが、null または空のアクセス トークンを使用してリクエストを作成することはできません。
質問: これは OAuth 標準の不適切な使用ですか? そうでない場合、DotNetOpenAuth ライブラリには、RequestToken (6.1) 以外のエンドポイントに無許可の要求を送信することを不可能にする制限がありますか? これらの両方に対する答えが「いいえ」の場合、DotNetOpenAuth を使用して、アクセス トークンやシークレットを送信せずに PlaceFinder データを要求するにはどうすればよいでしょうか?