Bem, uma instalação falhou (meu script de instalação obtém uma chave de API para que possa definir a mailgun_api_key). Também verifiquei na minha instância local de desenvolvimento.
$ 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)
Por curiosidade, você limpa a chave da API quando termina? Você pode ter notado que fiz muitas mudanças recentemente para que possamos rastrear melhor as chaves da API. Estamos tentando reduzir o risco de chaves de API “não utilizadas” ficarem como potenciais falhas de segurança.
Se isso estiver sendo executado no servidor, talvez você possa usar Ruby para definir a configuração do site, em vez de gerar e usar uma chave de API?
Oh! Acredito que seria melhor não alterar a chave se ela já existir ou ter uma tarefa chamada create_if_not_exists. É muito útil poder obter a chave existente com uma tarefa rake sem precisar alterá-la e quebrar qualquer coisa que a utilize.
Em alguns pontos das minhas ferramentas Ansible, se não tiver a chave da API, chamo essa tarefa rake para obter a existente, como:
- name: Obter chave da 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
Acho que a única vez em que é realmente necessário obtê-la dessa forma é durante uma instalação limpa. (Para sites existentes, tenho a chave da API nas variáveis daquele site.)
Suponho que, com o novo modo como as chaves são tratadas, eu pudesse excluir a chave quando terminasse ou, digamos, alterar as configurações do site de alguma forma executando um script do Rails dentro do container?
Uma mudança que fiz é que agora é possível ter várias chaves por usuário (ou múltiplas ‘chaves mestras’). Isso significa que cada integração pode receber sua própria chave, e elas podem ser auditadas, revogadas ou excluídas separadamente. Então, no seu caso, você poderia criar uma chave com a descrição “ferramentas de configuração do pfaffman”. Assim, os administradores do site saberão para que serve e poderão revogar/excluir quando não for mais necessária.
Quanto a como isso se traduziria em uma tarefa rake… não tenho certeza. Talvez pudéssemos ter uma tarefa como api:get_or_create "minha descrição de chave"
Desculpe @pfaffman, mas receio que terei que remover essa nova tarefa rake em um PR futuro. Vamos estar hashando as chaves de API no banco de dados, então será fundamentalmente impossível recuperar uma chave existente.
Substituí a tarefa get_or_create_master por uma tarefa create_master mais simples, que criará incondicionalmente uma nova chave. Se você quiser ter apenas uma chave, precisará manter o controle da chave no seu próprio sistema.
Espera. O quê?! Desde quando? Todo commit que tenho na minha cópia atual do Discourse no meu HD ainda possui o schema.rb. É realmente, realmente útil poder descobrir exatamente qual modelo você está procurando. Poder abrir um único arquivo e pesquisar algo (por exemplo, para descobrir qual modelo você pode estar procurando) é muito mais fácil do que procurar em mais de 200 arquivos em app/models. Nem existe uma boa maneira de fazer grep apenas no esquema no final dos modelos.
Se você não sabe qual modelo está procurando, como pode encontrá-lo? Como há várias tabelas relacionadas a “auth”, nem todas começando com auth, como você pode começar a descobrir onde procurar?
Por curiosidade, você limpa a chave da API quando termina? Você pode ter notado que fiz muitas mudanças recentemente para que possamos rastrear melhor as chaves da API. Estamos tentando reduzir o risco de chaves de API “não utilizadas” ficarem como potenciais falhas de segurança.
