API経由でuser_api_keys値を取得する方法

こんにちは。user_api_keysについて質問があります。現在、認証のためにDiscourseのuser_api_keysを統合するためにアプリに取り組んでいます。私の質問は、APIを使用してuser_api_keysを取得する方法があるかどうかということです。

現在、/session.json経由でログインし、/users/:username.jsonを使用して現在のユーザープロファイルを確認した後、ユーザーがuser_api_keysを持っているかどうかを確認できますが、実際の値は返されません。

"user_api_keys": [
  {
    "id": 0,
    "application_name": "",
    "scopes": [""],
    "created_at": "",
    "last_used_at": ""
  }
]

user_api_keysの値を取得したい理由は、ユーザーが最初のログイン時にボタンをクリックして既に承認している場合に、再度承認を求めることを回避するためです。

いいえ、一度表示されるだけで、その後はハッシュのみが保存されます。

ユーザーAPIキーは、アプリ内、できればエンドユーザーのデバイスに保存する必要があります。ユーザーAPIキーの存在理由は、ユーザーが承認の「証明」を持ち、それを保存する責任があるということです。

「いいね!」 2

API経由でAPIキーの値を取得することはできないと思います。Discourseは、暗号化されていないAPIキーをデータベースに保存しません。暗号化された値を取得できたとしても、アプリケーションでそれを復号する方法はありません。

ユースケースをもう少し詳しく説明していただけますか?ユーザーのAPIキーがすでに生成されている場合、なぜ再度承認が必要なのかが不明です。

編集:管理者APIキーを使用してユーザーのAPIキーを生成することは可能です。詳細はこちらをご覧ください: Generate User Api Key Without User Approval - #2 by simon

投稿を読み返すと、リクエストの$json変数がどのように設定されたかを説明していなかったことに気づきました。データの構造を把握する最も簡単な方法は、Discourse UIを通じて、使用したいスコープを持つ単一のユーザーAPIを生成するリクエストを行い、次に/admin/api/keysへのリクエストで送信されるリクエストペイロードの値を確認することです。

「いいね!」 2

RGJさん、回答ありがとうございます。

こんにちは @simon、ご返信ありがとうございます。ケースについて詳しくご説明させてください。

私たちは、Discourseのエンドポイントからのバックエンドロジックに依存するモバイルアプリを構築しています。ユーザーがアプリを通じてログインすると、ログインデータが session.json を介してDiscourse APIに送信され、Cookieが返されます。このCookieは、その後、user-api-key/new へのリダイレクトに使用され、ユーザーに承認を求めます。承認後、ペイロードはAPIキーに復号化されます。

この場合、APIキーをモバイルアプリ内のグローバルなトークンとして使用して、他のDiscourseエンドポイントにアクセスできます。しかし、ユーザーがログアウトすると、新しいトピックの作成などのエンドポイントにアクセスできないように、トークンはグローバル状態から削除されるべきです。

私の質問は、このトピックからです。ユーザーがすでに user_api_keys を持っているかどうか、そしてそれらがまだアクティブかどうかを確認するにはどうすればよいですか?キーが存在し、アクティブであれば、ユーザーはログイン後にそれらを使用できるはずです。そうでない場合は、ユーザーは新しい user_api_keys を作成する必要があります。これには、WebViewでの承認が必要になります。

これが私が直面している主な問題です。

別の解決策として、How to Retrieve User API Keys Value via API の投稿に基づいて、APIキーをモバイルアプリのデータベースに保存することを検討しました。

また、APIキーの実装について最初に参照した、Generate User API Key Without User Approval - #2 by simon の投稿も参照しました。しかし、問題は同じままです。/admin/api/keys を確認すると、データベースにすでに保存されているAPIキーの値を取得したり、ユーザーごとのAPIキーを取得したりすることはできません。この実装のためには、APIキーを独自のデータベースに保存する必要があると考えています。

APIキーとは別にセッショントークンを生成してみてはどうでしょうか。そのトークンを使用してユーザーのログイン状態を示します。そうすれば、ユーザーがログアウトしたときにAPIキーを削除する必要はありません。

「いいね!」 2

この問題に関するご意見ありがとうございます。トークンを2か所に保存するのが良いというのは同感です。まず、グローバルステートに保存してユーザーのログイン状態を確認し、次にデータベースに保存してuser_api_keysを格納します。

なぜDiscourse Connectを使用しないのですか?それが認証の方法です。

「いいね!」 1

こんにちは、ご提案ありがとうございます。ここでDiscourse Connectを使用しない理由は、Discourseを他のウェブサイトや他の場所と連携させていないためです。すべてのログイン機能はDiscourseで直接処理され、アプリはDiscourseとしかやり取りしません。

あなたのアプリは別の場所です。あなたのアプリをDiscourse Connectクライアントとして設定したいのだと確信しています。そうすれば、人々はDiscourseにログインすることであなたのアプリにログインできます。そうすれば、あなたのアプリはDiscourseと連携できると思います。あるいは、アプリの仕組みを理解していないのかもしれません。

「いいね!」 1

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.