Bueno, falló una instalación (mi script de instalación obtiene una clave API para poder establecer la mailgun_api_key). También lo verifiqué en mi instancia local de desarrollo.
$ 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)
¡Sí! Esto no rompió una instalación normal, solo la parte de mis tareas posteriores a la instalación que necesita una clave de API para configurar mailgun_api_key.
Sospecho que pocas personas utilizan esta tarea de Rake.
Por curiosidad, ¿limpias la clave de la API cuando terminas? Es posible que hayas notado que he realizado muchos cambios recientemente para que podamos hacer un mejor seguimiento de las claves de API. Estamos intentando reducir las claves de API “no utilizadas” que quedan como posibles vulnerabilidades de seguridad.
Si esto se está ejecutando en el servidor, ¿podrías usar Ruby para configurar la opción del sitio, en lugar de generar y usar una clave de API?
¡Oh! Creo que sería mejor no cambiar la clave si ya existe o tener una tarea llamada create_if_not_exists. Es muy útil poder obtener la clave existente con una tarea de Rake sin tener que modificarla y romper nada que la esté utilizando.
En varios lugares de mis herramientas de Ansible, si no tengo la clave de API, llamo a esa tarea de Rake para obtener la existente, así:
- name: Obtener clave de 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
Supongo que la única vez que realmente es necesario obtenerla de esta manera es cuando estoy realizando una instalación limpia. (Para sitios existentes, tengo la clave de API en las variables de ese sitio.)
Supongo que, con la nueva forma en que se manejan las claves, podría eliminar la clave cuando termine o, por ejemplo, cambiar la configuración del sitio ejecutando un script de Rails dentro del contenedor.
Un cambio que hice es que ahora puedes tener varias claves por usuario (o varias ‘claves maestras’). Esto significa que cada integración puede recibir su propia clave, y estas se pueden auditar, revocar o eliminar por separado. Así que, en tu caso, podrías crear una clave con la descripción “herramientas de configuración de pfaffman”. De esta forma, los administradores del sitio sabrán para qué sirve y podrán revocarla o eliminarla cuando ya no sea necesaria.
En cuanto a cómo se traduce esto a una tarea de Rake… no estoy seguro. Quizás podríamos tener una tarea como api:get_or_create "mi descripción de clave"
Lo siento @pfaffman, pero temo que tendré que eliminar esta nueva tarea de rake en un PR próximo. Vamos a estar hasheando las claves de API en la base de datos, por lo que será fundamentalmente imposible recuperar una clave existente.
He reemplazado la tarea get_or_create_master con una tarea create_master más simple, que creará incondicionalmente una nueva clave. Si solo quieres tener una clave, entonces tendrás que hacer un seguimiento de la clave en tu propio sistema.
Espera. ¿Qué?! ¿Desde cuándo? Cualquier commit que tengo en mi fuente actual de Discourse en mi disco duro todavía incluye schema.rb. Es realmente, realmente útil poder descubrir exactamente qué modelo estás buscando. Poder abrir un solo archivo y buscar algo (por ejemplo, para determinar qué modelo estás buscando) es mucho más fácil que buscar en más de 200 archivos en app/models. Ni siquiera hay una buena manera de hacer grep solo en el esquema al final de los modelos.
Si no sabes qué modelo estás buscando, ¿cómo puedes encontrarlo? Por ejemplo, hay varias tablas relacionadas con “auth”, y no todas comienzan con auth; ¿cómo puedes empezar a determinar dónde buscar?
Por curiosidad, ¿limpias la clave de la API cuando terminas? Es posible que hayas notado que he realizado muchos cambios recientemente para que podamos hacer un mejor seguimiento de las claves de API. Estamos intentando reducir las claves de API “no utilizadas” que quedan como posibles vulnerabilidades de seguridad.
