I find allowed_user_api_auth_redirects default of “discourse://auth_redirect” rather restrictive, especially because “discourse” does not appear to be a valid URI scheme.
Please explain the thinking behind this default. Thank you.
I am having this issue as well. If I initiate the API from a JS application, then automatically the allowed headers are: User-Api-Key, User-Api-Client-Id even though I do not need user API keys. All I want is a simple API key but I cannot get anything to work. If I try to pass Api-Key in the headers I get a CORS error since it expects User-Api-Key. But when I try to use User-Api-Key, I get 403 errors. I am stuck. I would think this is the base usage for using the APIs. I am not trying to do anything out of the ordinary. I am simply trying to create a new topic post.
「いいね！」 2
That is the custom URI scheme used by the DiscourseHub app for iOS and Android.
「いいね！」 6
I’ve got a question concerning the “read tokens” and “write tokens”. This comment here is from 2016, so this possibly had already been changed? Or are the defaults still only “read tokens”?
Background: I’m one of the coders behind a distributed social media system. We already do have connectors to non-federating systems. The idea is to write an addon for discourse as well. But when most likely most system won’t allow users to generate tokens that allow posting, we will try another way. We already do have a mail connector. Then we will simply use the mailing list function of Discourse and we will try to enhance the returned content and will post via SMTP.
You can do write tokens if you ask for the scope upfront
「いいね！」 3
Of course this is always possible. But I have the feeling that this is a support nightmare. Our software has got some hundred installations with (in total) more than 10k users. When they see that there is an addon that is connection to Discourse, many will surely like to use it. And since it most likely won’t work out of the box, this will generate questions and support work from our side. Additionally it will generate work for the admins of the several Discourse installations. And very likely not all will allow it - which will cause frustration.
So possibly at first I will focus on integrating the mailing list mode mails. Or is it possible to combine these two? Means: Reading of the posts via the API, but posting via 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