私は RSS デスクトップ クライアント用のプラグインを構築しています。これにより、ユーザーはクライアント内から直接フラットなもの (ブログ投稿など) を実行できます。これはJavaアプリケーションなので、 flattr4jを使用していますが、それ自体は今のところ問題なく動作しています。
残っている唯一の問題は、OAuth 2.0 を使用する承認ワークフローに集中しています。flattr はOAuth 2.0 仕様のセクション 4.1 で説明されている承認ワークフローを使用するため、そこに記載されている前提条件に従う必要があります。
認証コード許可タイプは、アクセス トークンとリフレッシュ トークンの両方を取得するために使用され、機密クライアント向けに最適化されています。リダイレクトベースのフローとして、クライアントはリソース所有者のユーザー エージェント (通常は Web ブラウザー) と対話でき、承認サーバーからの着信要求を (リダイレクト経由で) 受信できる必要があります。
私はこのワークフローを実装することができました
Web ブラウザー コントロールをアプリケーションに埋め込む (おそらく、ユーザーの実際の Web ブラウザーも使用できます)
OAuth コードを受信するために、OAuth コールバック URL メカニズムを介して Web ブラウザーからアクセスされる小さなローカル HTTP サーバーを実行する
特に最後のポイントは、私にはエラーが発生しやすいように見えます。事前にコールバック URL を登録する必要があるため (たとえば、私の場合http://localhost:port/whatever)、承認の最後に OAuth コードを受け取るローカル HTTP サーバーを実行するために、安全で未使用のローカル ポートについて推測する必要があります。ワークフロー。
反対側では、flattr4j のドキュメントには別のワークフローが記載されています。
「クライアント」ベースのアプリケーションは、コールバック URL を提供できません。たとえば、デスクトップやモバイル デバイスのアプリケーションは、Web サーバーをまったく実行しません。クライアントベースのアプリケーションの場合、Flattr は Web サイトに検証コードを表示します。ユーザーは、認証プロセスを完了するために、アプリケーションにコードを入力する必要があります。
そしてさらに下のいくつかの行：
ユーザーが同意すると、Flattr によって検証コードが生成されます。アプリケーションが「ブラウザ」タイプとして登録された場合、指定したコールバック URL がコードと状態をパラメータとして呼び出されます。「クライアント」アプリケーションの場合、代わりにコードがユーザーに提示され、アプリケーションに手動でコードを入力するよう求められます。
このワークフローは完璧ではないかもしれませんが、私の意見では、デスクトップ アプリケーションとしてははるかに堅牢です。
(アプリケーションの登録に関して: アプリケーションをプラットフォームDesktop (Any)に登録しました。プラットフォームは、上記の「ブラウザ」と「クライアント」の代替案と比較して、よりきめ細かいようです。)
だから私の質問は：
- コールバックのない OAuth ワークフローは Flattr で引き続きサポートされますか? （これまでサポートされていましたか？）
- その場合: このワークフローを開始するにはどうすればよいですか?
- そうでない場合：私の懸念は有効ですか、それとも「Webブラウザを開き、認証プロセスを開始し、ローカルで実行されているHTTPサーバーを介してOAuthコードを受信する」だけですか？私が見落とした代替手段はありますか？
更新現在調査中の別のオプションがあります。コールバック URL として使用される「OAuth ランディング ページ」を設定しました。この Web サイトの唯一の目的は、ユーザーがデスクトップ アプリケーションにコピーできる OAuth コードを表示することです。完璧ではありませんが、現時点ではより堅牢に見えます...