Что ж, установка не удалась (мой скрипт установки получает API-ключ, чтобы можно было установить mailgun_api_key). Я проверил это и на своей локальной среде разработки.
$ 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)
Из любопытства, вы очищаете API-ключ после завершения работы? Вы, возможно, заметили, что я внес много изменений в последнее время, чтобы мы лучше отслеживали API-ключи. Мы стараемся сократить количество «неиспользуемых» API-ключей, которые остаются потенциальными уязвимостями безопасности.
Если это выполняется на сервере, может быть, вы могли бы использовать Ruby для настройки параметра сайта, вместо генерации и использования API-ключа?
О! Думаю, было бы лучше не менять ключ, если он уже существует, или добавить задачу create_if_not_exists. Очень удобно иметь возможность получить существующий ключ с помощью задачи rake, не меняя его и не нарушая работу всего, что использует этот ключ.
В нескольких местах моих инструментов Ansible, если у меня нет API-ключа, я вызываю эту задачу rake для получения существующего, например:
- name: Получить API-ключ
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
Думаю, единственный случай, когда действительно необходимо получать его таким способом, — это при чистой установке. (Для существующих сайтов у меня API-ключ указан в переменных для этого сайта.)
Предполагаю, что с новым способом обработки ключей я мог бы удалять ключ после завершения работы или, скажем, как-то изменять настройки сайта, запуская rails-скрипт внутри контейнера?
Одно из изменений, которое я внёс, заключается в том, что теперь у одного пользователя может быть несколько ключей (или несколько «мастер-ключей»). Это означает, что каждой интеграции можно выделить свой ключ, и их можно независимо проверять, отзывать или удалять. В вашем случае вы могли бы создать ключ с описанием «Инструменты настройки pfaffman». Тогда администраторы сайта будут знать, для чего он используется, и смогут отозвать или удалить его, когда он больше не понадобится.
Что касается того, как это реализуется в задаче rake… Я не уверен. Возможно, мы могли бы создать задачу вида api:get_or_create "моё описание ключа"
Извините, @pfaffman, но, боюсь, мне придётся удалить эту новую задачу rake в следующем PR. Мы будем хешировать ключи API в базе данных, поэтому извлечение существующего ключа станет принципиально невозможным.
Я заменил задачу get_or_create_master на более простую create_master, которая безоговорочно создаст новый ключ. Если вы хотите иметь только один ключ, вам нужно будет отслеживать его в своей собственной системе.
Я не могу быстро ответить. (Подождите. Почему в директории db нет файла schema.rb?)
Если я выполню несколько раз команду rake api_key:create_master['some name'] с одним и тем же значением some name, будет ли это ошибкой? То есть, должно ли это имя быть уникальным?
Погодите, что?! С каких пор? В любой моей текущей версии исходного кода Discourse на жёстком диске всё ещё есть schema.rb. Это действительно, очень удобно — иметь возможность быстро найти нужную модель. Открыть один файл и поискать в нём (например, чтобы понять, какую модель вы ищете) гораздо проще, чем просматривать более 200 файлов в app/models. Даже нет удобного способа выполнить grep только по схеме в конце моделей.
Если вы не знаете, какую модель ищете, как её найти? Например, есть много таблиц, связанных с «auth», но не все они начинаются с auth. Как вообще понять, где искать?
Из любопытства, вы очищаете API-ключ после завершения работы? Вы, возможно, заметили, что я внес много изменений в последнее время, чтобы мы лучше отслеживали API-ключи. Мы стараемся сократить количество «неиспользуемых» API-ключей, которые остаются потенциальными уязвимостями безопасности.
