3

重複した質問かもしれませんが、まだ回答がありません。ライブラリ oauth-dot-net と DotNetOpenAuth はどちらも恐ろしく複雑で、テーマは OAuth を介して実行されているようですが、 OAuth with Verification in .NETは有益で理解しやすいと書かれています。

WebBrowser コントロールを使用して、デスクトップ アプリ内で認証 Web ページを開きます。ユーザーが [許可] をクリックすると、その WebBrowser コントロールから応答テキストを取得し、PIN を自動的に抽出して、アクセス トークンを取得します。5 つまたは 6 つの HTTP 要求を送信しますが、ユーザーは 1 つの許可/拒否ダイアログのみを表示する必要があります。単純。

これはブラウザなしの OAuth ですか? いいえ、そうではありません。Web ブラウザーを使用して URL を呼び出し、応答を実行すれば、それは機能します。これは、HTML、メタ リフレッシュ、noscript タグ、および JavaScript でのブラウザー ベースの自動化のすべてを歌い、すべてを踊る奇跡です。しかし、私はこれをしたくありません。

マイクロソフト、これはあなたに向けられています! javascript の場合を除いて、ほとんどの場合REST ではなく、純粋な REST を実行する必要があります。

OAuth RFC で説明されているように、リクエスト トークンを取得したいと考えています。ソフトウェア認証ロボットではなく、リクエスト トークン。リクエストトークン。

WebClient を使用してこの GET を直接実行すると

GET /oauth20_authorize.srf?client_id=00000000400A9B87&scope=wl.signin%20wl.basic&response_type=code&redirect_uri=http%3a%2f%2fwhitehouse.podzone.net%2f HTTP/1.1

機械で生成された JavaScript の言いようのない混乱が返ってきます。ピートの愛のために、javascript のラブインではなく、とんでもない request_token が欲しい。では、どうすれば live.com からリクエスト トークンを取得できますか?

私は現在、送信された HTML によって参照される難読化および圧縮されたライブラリを調べていますが、それは大変なことです。誰かがすでにこれを行っている場合、私は支援に非常に感謝しています. または、このページのスクリプトをハイジャックしてトレースする方法についてのガイダンスもあれば、かなりのスピードアップになるでしょう。

GET を調べている場合、リダイレクト URI http://whitehouse.podzone.net/は自宅のデスクトップ マシンの Web サーバーにマップされます。これは通常、デバッグ中のアプリケーションの HttpListener、場合によっては IIS です。それが私がリダイレクトを処理する方法です (通常はドロップしますが、そこまで到達したことを知っておくと便利です)。

私は、Skydrive に関する他の誰かの作業に基づいて、私が行ったいくつかの作業から短期的なハックを解除しました。Skydrive アプリケーションがすべての Live アカウントに対して事前承認されているという事実を利用して、この問題を回避します。ただし、これはハックです。OAuth を適切に使いたいのですが、それは実用的ではないようです。

初日に見たかったものを見つけてくれた Darin からの非常に勇敢な試みにもかかわらず、彼のリンクhttp://msdn.microsoft.com/en-us/libraryからのこの引用が残されています。 /live/hh826529.aspx (強調)

クライアント側の認証フローを実装するには、デスクトップ アプリで Web ブラウザー コントロールを使用する必要があります。ほとんどの開発言語には、このようなコントロールが含まれています。この例では、アプリは System.Windows.Forms.WebBrowser クラスを使用します。サインインが完了すると、以降のすべての Live Connect API 呼び出しは、System.Net.WebRequest クラスを使用して実行できます。Web ブラウザー コントロールを使用してサインインを開始し、このような URL を渡します。

取引所の制御を放棄すると、ユーザー介入の機会を提示するのをスキップすることが難しくなるため、サインインのためにロボットを使用することだけを望んでいます。サインイン手順を自分で実装できない固有の理由はありません。彼らのJavaScriptが投稿できるものはすべて、WebClientで投稿できます。同じ暗号化を行うことができます。倫理的なレベルでは、私のソフトウェアにそのようなことをさせたくない場合、ユーザーは自分のユーザー名とパスワードを提示することはほとんどありません。

Darin の回答をマークアップしました。なぜなら、彼は非常に熱心に支援し、いくつかの優れたものを提示したからです。

4

1 に答える 1

4

implicit grant flowをリッチ クライアント アプリケーションで使用できます ( grant_type=token)。アイデアは、live.com 承認サーバーにリダイレクトし、コールバック URL を提供することによって認証フローを開始する WebBrowser コントロールを持つことです。ユーザーがアプリケーションを承認すると、live.com はコールバック URL にリダイレクトし、URL でアクセス トークンを渡します。

http://contoso.com/Callback.htm#access_token=ACCESS_TOKEN

access_token次に、WebBrowser から URLのフラグメントを取得し、それを使用して認証済みの要求を実行できます。返されたコンテンツを WebBrowser 内で解析する必要はありません。必要なことは、URL からアクセス トークンを取得することです。

Web ベースのアプリケーションにより適したauthorization grant code flow( )もあります。grant_type=code

following articleデスクトップ アプリケーションを使用した完全なサンプルについては、 を参照してください。

于 2013-02-24T09:51:51.717 に答える