Eh bien, une installation a échoué (mon script d’installation récupère une clé API afin de définir la mailgun_api_key). J’ai également vérifié sur mon instance de développement locale.
$ 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)
Oui ! Cela n’a pas cassé une installation normale, seulement la partie de mes tâches post-installation qui nécessite une clé API pour définir mailgun_api_key.
Je soupçonne que peu de personnes utilisent cette tâche rake.
Par curiosité, effaces-tu la clé API une fois terminé ? Tu as peut-être remarqué que j’ai apporté pas mal de changements récemment afin que nous puissions mieux suivre les clés API. Nous essayons de réduire le nombre de clés API « inutilisées » laissées comme de potentielles failles de sécurité.
Si cela s’exécute sur le serveur, pourrais-tu utiliser Ruby pour définir le paramètre du site, plutôt que de générer et d’utiliser une clé API ?
Oh ! Je pense qu’il serait préférable de ne pas modifier la clé si elle existe déjà, ou de disposer d’une tâche create_if_not_exists. Il est très pratique de pouvoir récupérer la clé existante via une tâche Rake sans avoir à la modifier et casser tout ce qui l’utilise.
Dans plusieurs endroits de mes outils Ansible, si je n’ai pas la clé API, j’appelle cette tâche Rake pour récupérer celle qui existe déjà, comme ceci :
- name: Récupérer la clé 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
Je suppose que la seule fois où il est vraiment nécessaire de l’obtenir ainsi est lors d’une installation propre. (Pour les sites existants, j’ai la clé API dans les variables de ce site.)
Je suppose qu’avec la nouvelle façon de gérer les clés, je pourrais supprimer la clé une fois terminé, ou, par exemple, modifier les paramètres du site en exécutant un script Rails à l’intérieur du conteneur ?
Une modification que j’ai apportée est que vous pouvez désormais avoir plusieurs clés par utilisateur (ou plusieurs « clés maîtresses »). Cela signifie que chaque intégration peut se voir attribuer sa propre clé, et elles peuvent être auditées, révoquées ou supprimées séparément. Dans votre cas, vous pourriez donc créer une clé avec la description « outil de configuration de pfaffman ». Les administrateurs du site sauraient alors à quoi elle sert et pourraient la révoquer ou la supprimer lorsqu’elle n’est plus nécessaire.
Quant à la manière dont cela se traduit dans une tâche Rake… je ne suis pas sûr. Peut-être pourrions-nous avoir une tâche du type api:get_or_create "ma description de clé"
Est-ce que cela fonctionnerait pour votre cas @pfaffman ?
Désolé @pfaffman, mais je crains devoir supprimer cette nouvelle tâche Rake dans une prochaine PR. Nous allons hacher les clés API dans la base de données, il sera donc fondamentalement impossible de récupérer une clé existante.
J’ai remplacé la tâche get_or_create_master par une tâche create_master plus simple, qui créera inconditionnellement une nouvelle clé. Si vous ne souhaitez qu’une seule clé, vous devrez alors suivre cette clé dans votre propre système.
Je ne peux pas le dire rapidement. (Attends. Comment se fait-il qu’il n’y ait pas de fichier schema.rb dans le répertoire db ?)
Si j’exécute plusieurs fois rake api_key:create_master['some name'] avec le même some name, cela va-t-il échouer ? Autrement dit, ce nom doit-il être unique ?
Les descriptions n’ont pas besoin d’être uniques, non. Cependant, cela pourrait devenir assez confus si vous créez de nombreuses clés qui se ressemblent.
Nous ne commitons pas le fichier schema.rb. Le meilleur endroit pour chercher se trouve dans les annotations au bas de chaque fichier sous /app/models.
Attends. Quoi ?! Depuis quand ? Quel que soit le commit que j’ai dans ma source actuelle de Discourse sur mon disque dur, il contient toujours schema.rb. C’est vraiment, vraiment pratique de pouvoir trouver quel modèle on cherche. Pouvoir ouvrir un seul fichier et y rechercher quelque chose (par exemple, pour déterminer quel modèle on cherche) est beaucoup plus simple que de parcourir plus de 200 fichiers dans app/models. Il n’existe même pas de bonne méthode pour faire un grep uniquement sur le schéma à la fin des modèles.
Si vous ne savez pas quel modèle vous cherchez, comment pouvez-vous le trouver ? Par exemple, il y a plusieurs tables liées à l’« auth », et toutes ne commencent pas par « auth » ; comment pouvez-vous commencer à déterminer où chercher ?
Par curiosité, effaces-tu la clé API une fois terminé ? Tu as peut-être remarqué que j’ai apporté pas mal de changements récemment afin que nous puissions mieux suivre les clés API. Nous essayons de réduire le nombre de clés API « inutilisées » laissées comme de potentielles failles de sécurité.
