Rake api_key:get が壊れている

サポート
1

さて、インストールが失敗しました（インストールスクリプトは mailgun_api_key を設定するために API キーを取得します）。ローカル開発インスタンスでも確認しました。

$ rake api_key:get
rake aborted!
NoMethodError: undefined method `create_master_key' for ApiKey (call 'ApiKey.connection' to establish a connection):Class
Did you mean?  create_with
/home/pfaffman/src/discourse/lib/tasks/api.rake:5:in `block in <main>'
Tasks: TOP => api_key:get
(See full trace by running task with --trace)

これは このコミット です。@david

PR はこちらです: FIX: create_master_key got renamed by pfaffman · Pull Request #8325 · discourse/discourse · GitHub

2

@pfaffman さん、ありがとうございます。PR にコメントしました。

確認ですが、これは標準のインストールスクリプトではなく、あなた個人のスクリプトでしょうか？

3

はい！通常のインストールには影響はありませんでした。API キーを必要とする mailgun_api_key の設定を行う、インストール後の処理の一部のみが機能しなくなりました。

この rake タスクを使っている人は少ないと思います。

4

:+1: 興味本位で伺いますが、作業が完了したら API キーを削除していますか？最近、API キーの管理をより確実に行えるよう、多くの変更を加えました。未使用の API キーがセキュリティ上の潜在的な脆弱性として残らないようにすることを目標としています。

もしこれがサーバー上で実行されている場合、API キーを生成して使用する代わりに、Ruby を使ってサイト設定を設定することは可能でしょうか？

5

おっと！もしキーが既に存在する場合は変更しないか、create_if_not_exists タスクを用意した方がよいと思います。rake タスクで既存のキーを取得し、それを変更せずにキーを使用している他の部分を壊さずに済むのは非常に便利です。

私の Ansible ツールリングでは、API キーを持っていない場合、以下のようにその rake タスクを呼び出して既存のキーを取得しています。

- name: Get api key
  block:
    - shell: docker exec -w /var/www/discourse -i {{ discourse_yml }}  rake api_key:get
      register: get_api_key

    - set_fact:
        discourse_api_key: "{{ get_api_key.stdout }}"

  when: discourse_api_key is not defined

本当にこの方法で取得する必要があるのは、クリーンインストールを行っている時だけだと思います。（既存のサイトについては、そのサイトの vars に API キーを保持しています。）

新しいキーの扱い方であれば、使用後にキーを削除するか、あるいはコンテナ内で Rails スクリプトを実行してサイト設定を変更する方法もあるかもしれませんね。

6

[quote=“pfaffman, 投稿:5, トピック:132948”]
rake タスクで既存のキーを取得できるようにするのは非常に便利ですね。変更して何かを壊す必要がありません。[/quote] 変更した点の一つとして、ユーザーごとに複数のキー（または複数の「マスターキー」）を持たせられるようにしました。つまり、各統合に独自のキーを割り当てることができ、それらを個別に監査・無効化・削除できるようになりました。したがって、あなたのケースでは、「pfaffman のセットアップツール」という説明付きのキーを作成できます。そうすれば、サイト管理者はその用途を理解でき、不要になった時点で無効化や削除が可能になります。rake タスクへの適用方法については確信が持てません。もしかすると、api:get_or_create "my key description" というタスクを用意できるかもしれませんね :thinking: @pfaffman さん、これであなたのケースに対応できるでしょうか？

7

もちろん！それは素晴らしいと思います。

8

こちらはどうでしょうか？[FIX: create_master_key got renamed by pfaffman · Pull Request #8325 · discourse/discourse · GitHub]

rake api_key:get_or_create_master["Onboarding Key"]

問題がなければ数時間以内にマージします。

10

私には良さそうです！それに、私のプレイブックはエディタで開いたままだったので、もうコミット済みです。:slight_smile:

11

マージ済み

16

@pfaffman さん、申し訳ありませんが、今後の PR でこの新しい rake タスクを削除せざるを得なくなります。API キーをデータベースでハッシュ化することになるため、既存のキーを取得することは本質的に不可能になります。

get_or_create_master タスクは、単純な create_master タスク に置き換えました。これは無条件に新しいキーを作成します。キーを 1 つだけ保持したい場合は、ご自身のシステムでキーを管理する必要があります。

17

そうですね。それも予想していました。他のシステムでは API キーは一度しか表示されないため……

お気遣いありがとうございます！

18

すぐに判断できません。（待って、dbディレクトリにschema.rbがないのはなぜ？）

同じsome nameで複数のrake api_key:create_master['some name']を実行すると失敗しますか？つまり、その名前は一意である必要がありますか？

19

説明文は一意である必要はありません。ただし、見た目が似たキーを多数作成すると、かなり混乱する可能性があります。

schema.rb ファイルはコミットしていません。確認すべき最良の場所は、/app/models 配下の各ファイルの下部にある注釈です。

20

えっ、何？いつからですか？私のハードドライブにある現在の Discourse ソースには、まだ schema.rb が含まれています。どのモデルを探しているのかをすぐに把握できるのは、本当に、本当に便利です。単一のファイルを開いて何かを検索する（例えば、どのモデルを探しているのかを特定する）のは、app/models 内の 200 以上のファイルを探すよりもはるかに簡単です。モデルの末尾にあるスキーマだけを grep で検索する良い方法さえありません。

探しているモデルがわからない場合、どうやって見つけるのでしょうか？「auth」に関連するテーブルがいくつかあり、すべてが auth で始まるわけではないので、どこを探せばよいのかどうやって判断できるのでしょうか？

21

最初からですよ。.gitignore ファイルに含まれています。ただし、db:migrate を実行すると生成されるため、ローカルには存在します。

テーブル名は常にモデル名と一致するので、ファイル名を使っています :man_shrugging:

22

なるほど。私の知識不足でした。:wink 解説ありがとう。

テーブルやモデルの名前がわからないこともあるので、すべてのフィールドを一处にまとめられているのは非常に助かります。