allowed_user_api_auth_redirectsのデフォルト値が「discourse://auth_redirect」であるのは、特に「discourse」が有効なURIスキームではないように見えるため、かなり制限的だと感じます。
このデフォルト値の背景にある考え方を説明いただけますでしょうか。よろしくお願いいたします。
私も同様の問題に直面しています。JS アプリケーションから API を開始すると、自動的に許可されるヘッダーは User-Api-Key と User-Api-Client-Id になります。しかし、ユーザー API キーは必要ありません。単純な API キーだけで動作させたいのですが、何も機能しません。ヘッダーに Api-Key を渡そうとすると、User-Api-Key を期待しているため CORS エラーが発生します。一方、User-Api-Key を使用しようとすると 403 エラーになります。行き詰まっています。これは API を使用する際の基本的な使い方であるはずです。特別なことをしようとしているわけではありません。単に新しいトピック投稿を作成しようとしているだけです。
「いいね！」 2
これは、DiscourseHub アプリ（iOS および Android）で使用されるカスタム URI スキーマです。
「いいね！」 6
「読み取りトークン」と「書き込みトークン」について質問があります。このコメントは2016年のものですが、すでに仕様が変わっている可能性はありますか？それとも、デフォルトは依然として「読み取りトークン」のみなのでしょうか？
背景：私は分散型ソーシャルメディアシステムの開発者の一人です。すでにフェデレーションを行わないシステム向けのコンネクタを持っています。Discourse用のアドオンも作成する予定です。しかし、ほとんどのシステムが投稿を許可するトークンの生成をユーザーに認めない可能性が高いため、別の方法を試みるつもりです。すでにメール用のコンネクタがありますので、Discourseのメーリングリスト機能を活用し、返されるコンテンツを強化してSMTP経由で投稿する方法を検討しています。
スコープを事前に指定すれば、書き込みトークンを作成できます。
「いいね！」 3
もちろん、それは常に可能です。しかし、これはサポートの悪夢になるような気がします。私たちのソフトウェアには数百のインストールがあり、合計で1万人以上のユーザーがいます。Discourseと連携するアドオンがあることを知れば、多くのユーザーがそれを使いたがるでしょう。そして、それがすぐに動作するとは限らないため、当社側から多くの質問やサポート作業が発生します。さらに、複数のDiscourseインスタンスの管理者にも作業が増えます。おそらくすべての環境で許可されるわけではないため、フラストレーションを招く可能性が高いです。
したがって、まずはメーリングリストモードのメールの統合に注力するかもしれません。あるいは、この2つを組み合わせることは可能でしょうか？つまり、APIを通じて投稿を読み取り、SMTPを通じて投稿するといった方法です。
こんにちは…public_key の生成方法がわかりません。RSA 生成器を使って公開鍵/秘密鍵ペアを取得すべきでしょうか？
もしそうであれば、いくつかのオンライン RSA 生成器を試しましたが、以下のエラーが発生します：
OpenSSL::PKey::RSAError (Neither PUB key nor PRIV key: nested asn1 error) /var/www/discourse/app/controllers/user_api_keys_controller.rb:189:in `initialize'
また、私のユースケースに適しているか皆様にお伺いしたいことがあります：
私はアプリを持っており、基本的にユーザーを認証してユーザー名を取得したいと考えています。ユーザーのログインを検証するために、API キーのフローが最も簡単な方法でしょうか？可能であれば、より複雑に見える SSO は避けたいと考えています。
私も同じ状況です。ただし、私は Api-Key ではなく User-Api-Key を使用してトピック投稿を作成しようとしており、actionpack ライブラリから CSRF 拒否のエラーが発生しています。Discourse サーバーで CSRF チェックが無効になっていない限り、サードパーティのデスクトップアプリからの投稿は難しいようです。ブラウザをエミュレートするつもりはありません。
@sam read スコープのみが付与されたユーザー API キーを、GET リクエストの URL パラメータとして渡すことについて、あなたの考えを聞かせてください。
ユースケースの例として、ユーザー API キーを使用して、リマインダー付きの改善されたブックマーク を Google カレンダーにサブスクライブするなどの統合を可能にすることです。
「いいね！」 5
特定の新しいスコープを作成し、3 番目のパラメータで「get パラメータが許可されている」ことを示すのはどうでしょうか。そうすれば、他の用途（例えば CORS の回避や、別のサイトからの Discourse API へのリクエストなど）に誤用されるのを防げます。
(ここから)
SCOPES = {
read: [:get],
write: [:get, :post, :patch, :put, :delete],
message_bus: [[:post, 'message_bus']],
push: nil,
one_time_password: nil,
notifications: [[:post, 'message_bus'], [:get, 'notifications#index'], [:put, 'notifications#mark_read']],
session_info: [
[:get, 'session#current'],
[:get, 'users#topic_tracking_state'],
[:get, 'list#unread'],
[:get, 'list#new'],
[:get, 'list#latest']
],
+ calendar: [ [:get, 'users#bookmarks_cal', true ] ],
}
（余談ですが、なぜここでネストされた配列を使っているのでしょう…）
「いいね！」 10
API キーがユーザーレベルで明示的に「GET 使用可」とフラグ付けされる点は気に入っています。
全体として、このオプションは任意の GET リクエストに対して開放できるかもしれません。私が推奨するルールは、このモードで動作する際に以下の通りです：
- ユーザーの API キーは、特定の 1 つの GET コントローラーアクションに 100% 制限される
- ユーザーの API キーは、GET クエリパラメータでの使用が許可されているとフラグ付けされる
これにより、プロキシ経由での漏洩による影響を最小限に抑えられます。なぜなら、キーは再利用されることはないからです。
{get: 'list#new'}, {get: 'list#latest'} という形式でも機能するかもしれません。
「いいね！」 7
get param only タイプのユーザー API キーに非常に興味があります。UI を通じてこれらのキーを生成できるようにする予定はありますか？
おそらく、サイト設定またはプラグインを介して実装されているでしょう。管理用 API キーもスコープをサポートするように、機能セットをある程度標準化することを計画しています。
「いいね！」 4
こんにちは。この問題を解決できますか？私も同じ問題に直面しており、修正できません。さまざまな種類のキーを試しましたが、どれも機能しませんでした。ご協力をいただければ幸いです。
これに対応するライブラリはありますか？もしなければ、実装例はありますか？私は PHP を使って、ウェブサイトの別の部分でユーザーの Discourse アカウントを識別しようとしています。これは修正された OAuth フローのようですが、実装方法が少しわかりません。
具体的には、公開鍵と秘密鍵の生成全体をどう行えばよいのかわかりません。
Discourse を OAuth プロバイダーとして、OAuth 2 をそのまま使うことはできますか？
「いいね！」 2
User-Api-Keyを使ってこの操作に成功しましたか？私も「You are not permitted to view the requested resource」というエラーが表示されています。
「いいね！」 1
何が間違っていたか分かりました：返されたペイロードは UserAPI キーそのものではなく、秘密鍵/公開鍵ペアの秘密鍵で復号化する必要がある暗号化された JSON 文字列です。
「いいね！」 2
編集：大部分は動作するようになりました。完全に動作するようになったら、その説明を提供します。
クライアントはどのようにして秘密鍵/公開鍵のペアと ID を取得するのでしょうか？
JavaScript アプリでユーザーの API キーを取得するためのコードを提供していただけますか？（Discourse フォーラムに対して API 呼び出しを行うことをユーザーに許可する JavaScript アプリです）。
403 エラーが発生しています。あるいは、「申し訳ありませんが、ユーザー API キーの発行はできません。この機能はサイト管理者によって無効化されている可能性があります」というエラーが表示されます（私のサイトでは「ユーザー API キーの生成を許可する」がチェックされていますが）。
問題は、秘密鍵/公開鍵のペアを生成する方法（どのように生成するのか？）と、その後リダイレクトを処理する方法にあるのではないかと思っています。
コードの提供を歓迎します。
いくつかの試行錯誤の末、これを動作させることができました。
私が従っている基本的な手順を以下に示します。私が独自にコーディングした別のアプリがあり、そのアプリを使ってユーザーが Discourse サイトに対して API 呼び出しを行えるようにしたい場合の手順です。
そのためには、Node.js/JavaScript 環境では、少なくとも各特定のユーザーに代わって呼び出しを行うための、ユーザーごとの API トークンを生成する必要があります。
JavaScript 側については、@KengoTODA がここで提供してくれたコードが非常に役立ちました：discourse-api-key-generator/src/index.ts at main · KengoTODA/discourse-api-key-generator · GitHub
私が従った手順は以下の通りです：
第一：公開鍵と秘密鍵のペアを生成する。
これはあなたのアプリが生成する必要があるものです。公開鍵と秘密鍵です。GitHub Gist にそのための方法が提供されています。
第二：リダイレクト URL を設定する。
これは、Discourse が最終的な API トークンをペイロードとして含めてリダイレクトする URL です。デスクトップアプリ（ブラウザ URL を持たないもの）の場合、リダイレクト URL は、ブラウザで入力された際にアプリを起動するように設定したカスタムプロトコルに基づきます。
なお、リダイレクト URL は、対象の Discourse サイトのサイト設定でホワイトリストに登録されている必要があります。
また、Discourse サイト側でも「ユーザー API キーを許可する」というサイト設定がチェックされている必要があります。このトピックのオリジナル投稿で「サイト設定」について確認してください。
第三：Discourse のリクエスト URL に対して API リクエスト呼び出しを送信する。
つまり、アプリは以下のような形式の URL に対して呼び出しを送信します。
https://[対象の Discourse サイト .com]/user-api-key-new
そして、以下のパラメータを追加します。
- アプリ名
- 「client_id」（デスクトップアプリの場合、上記の GitHub Gist と同様に、
const {hostname} = require('os')からhostname()を使用できました） - スコープ（API を通じてユーザーが行える操作のスコープです。「write」や「read」など）
- 公開鍵（上記のステップ 1 から）
- リダイレクト URL（上記のステップ 2 から）
- nonce（これはあなたが選べる値です。例えば ‘1’ を使うだけで動作するようです）
第四：リクエスト URL によって開かれた Discourse サイトのページで、ユーザーがアプリを承認する
リクエスト URL が正常に送信されると、Discourse サイトのページが開き、アプリがサイトにアクセスしたい旨をユーザーに伝えます。
そのページには、ユーザーがこれを許可するためのボタンがあります。ユーザーがこのボタンをクリックすると、Discourse サイトは提供されたリダイレクト URL にリダイレクトし、?payload=[API キー] というパラメータを付加します。ここでいう API キーは、アプリで復号化する必要があるキーです。
第五：アプリがリダイレクト URL の値（ペイロード値を含む）を取得し、API キーを復号化する
もうすぐ完了です。アプリは、Discourse がリダイレクトした URL を解析し、ペイロードに含まれる API キーを取得する必要があります。
その API キーを取得したら、以下の 2 つのことを行う必要があります。
- URL エンコードされたバージョンではなく、実際のキーを取得する：URL からパラメータを取得する場合、それはよく URL エンコードされていることがあります（% が所々に追加されるなど）。これを整理する必要があります。JavaScript では、
decodeURIComponentがこれに有効であることがわかりました。 - Discourse から返されたクリーンな API キーを取得したら、それを復号化する必要があります。これを行うには、秘密鍵を使った JavaScript による復号化を使用します。基本的には、上記のステップ 1 で生成した秘密鍵を使用して、クリーンな API キーを復号化します。上記で参照した GitHub Gist に、いくつかの JavaScript の例があります：discourse-api-key-generator/src/index.ts at main · KengoTODA/discourse-api-key-generator · GitHub
復号化コードを実行すると、トークン自体が得られます。これを使って、ユーザーに代わって認証された API 呼び出しを行うことができます。
第六：トークン（つまり、最終的に整理され、復号化された API キー）を使用して、ユーザーに代わって API 呼び出しを行う
そのトークンがあれば、API 呼び出しにユーザー名を入力する必要はないようです。GET、POST、PUT などの呼び出しに以下のヘッダーを含めれば十分であることがわかりました。
headers: {
"User-Api-Key": [トークン]
}
これで、Discourse と対話するための、ユーザーごとの認証方法が動作するはずです。
「いいね！」 7
allowed_user_api_auth_redirects に項目を追加することのセキュリティへの影響は何ですか？NextCloud 統合をサポートするために文字列を追加するよう依頼されています。
「いいね！」 1