Bene, un’installazione è fallita (il mio script di installazione ottiene una chiave API in modo da poter impostare mailgun_api_key). L’ho verificato anche sulla mia istanza di sviluppo 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)
Sì! Questo non ha rotto un’installazione normale, solo la parte delle mie operazioni post-installazione che richiede una chiave API per impostare mailgun_api_key.
Sospetto che poche persone usino questo task rake.
Per curiosità, cancelli la chiave API una volta finito? Avrai notato che ho apportato molte modifiche recenti per tenere un migliore traccia delle chiavi API. Stiamo cercando di ridurre il numero di chiavi API “non utilizzate” lasciate come potenziali falle di sicurezza.
Se questo viene eseguito sul server, potresti usare Ruby per impostare la configurazione del sito, invece di generare e utilizzare una chiave API?
Oh! Penso che sarebbe meglio non modificare la chiave se esiste già, oppure avere un task create_if_not_exists. È molto utile poter ottenere la chiave esistente tramite un task rake senza doverla modificare e rompere qualcosa che la utilizza.
In alcuni punti dei miei strumenti Ansible, se non ho la chiave API, chiamo quel task rake per ottenerne una esistente, ad esempio:
- name: Ottieni chiave 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
Immagino che l’unico momento in cui sia davvero necessario ottenerla in questo modo sia durante un’installazione pulita. (Per i siti esistenti ho la chiave API nelle variabili di quel sito.)
Suppongo che, con il nuovo modo in cui vengono gestite le chiavi, potrei eliminare la chiave quando ho finito o, diciamo, modificare in qualche modo le impostazioni del sito eseguendo uno script Rails all’interno del contenitore?
Una modifica che ho apportato è che ora è possibile avere più chiavi per utente (o più “chiavi master”). Ciò significa che ogni integrazione può ricevere la propria chiave, che può essere verificata, revocata o eliminata separatamente. Quindi, nel tuo caso, potresti creare una chiave con la descrizione “strumentazione di configurazione di pfaffman”. In questo modo, gli amministratori del sito sapranno a cosa serve e potranno revocarla o eliminarla quando non sarà più necessaria.
Per quanto riguarda come questo si traduce in un task rake… non sono sicuro. Forse potremmo avere un task del tipo api:get_or_create "la mia descrizione chiave"
Mi dispiace @pfaffman, ma temo che dovrò rimuovere questa nuova rake task in una futura PR. Stiamo per eseguire l’hashing delle chiavi API nel database, quindi sarà fondamentalmente impossibile recuperare una chiave esistente.
Ho sostituito il task get_or_create_master con un task create_master più semplice, che creerà incondizionatamente una nuova chiave. Se desideri avere una sola chiave, dovrai tenere traccia della chiave nel tuo sistema.
Aspetta. Cosa?! Da quando? Qualsiasi commit ho attualmente nel mio codice sorgente di Discourse sul disco rigido contiene ancora schema.rb. È davvero, davvero utile poter scoprire esattamente quale modello stai cercando. Poter aprire un singolo file e cercare qualcosa (ad esempio, per capire quale modello stai cercando) è molto più facile che cercare in oltre 200 file in app/models. Non c’è nemmeno un buon modo per poter grep solo lo schema alla fine dei modelli.
Se non sai quale modello stai cercando, come puoi trovarlo? Ci sono un sacco di tabelle relative all’autenticazione, non tutte delle quali iniziano con auth; come puoi iniziare a capire dove cercare?
Per curiosità, cancelli la chiave API una volta finito? Avrai notato che ho apportato molte modifiche recenti per tenere un migliore traccia delle chiavi API. Stiamo cercando di ridurre il numero di chiavi API “non utilizzate” lasciate come potenziali falle di sicurezza.
