Rake api_key:get defekt

Unterstützung
1

Nun, eine Installation ist fehlgeschlagen (mein Installations-Skript ruft einen API-Schlüssel ab, um die mailgun_api_key festzulegen). Ich habe das auch auf meiner lokalen Entwicklungsumgebung überprüft.

$ 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)

Es ist dieser Commit. @david

Hier ist der PR: FIX: create_master_key got renamed by pfaffman · Pull Request #8325 · discourse/discourse · GitHub

2

Danke @pfaffman, ich habe einen Kommentar im PR hinterlassen.

Nur zur Sicherheit – ist das dein persönliches Skript und nicht das Standard-Installations-Skript?

3

Ja! Das hat eine normale Installation nicht beeinträchtigt, sondern nur den Teil meiner Nachinstallationsroutine, der einen API-Schlüssel benötigt, um mailgun_api_key zu setzen.

Ich vermute, dass nur wenige Leute diesen Rake-Befehl nutzen.

4

:+1: Aus Interesse: Löschen Sie den API-Schlüssel, wenn Sie fertig sind? Sie haben vielleicht bemerkt, dass ich kürzlich viele Änderungen vorgenommen habe, damit wir API-Schlüssel besser verfolgen können. Wir versuchen, „unbenutzte

5

Oh! Ich denke, es wäre besser, den Schlüssel nicht zu ändern, wenn er bereits existiert, oder eine Aufgabe namens create_if_not_exists einzuführen. Es ist sehr praktisch, den vorhandenen Schlüssel mit einem Rake-Task abrufen zu können, ohne ihn ändern zu müssen und damit alles zu zerstören, was den Schlüssel verwendet.

An einigen Stellen meiner Ansible-Werkzeuge rufe ich diesen Rake-Task auf, um den vorhandenen Schlüssel zu erhalten, falls ich keinen API-Schlüssel habe, wie hier:

- name: API-Schlüssel abrufen
  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

Ich vermute, dass dies wirklich nur bei einer sauberen Installation erforderlich ist. (Für bestehende Sites habe ich den API-Schlüssel in den Variablen für diese Site.)

Ich nehme an, mit der neuen Art, wie Schlüssel gehandhabt werden, könnte ich den Schlüssel löschen, wenn ich fertig bin, oder beispielsweise die Site-Einstellungen ändern, indem ich ein Rails-Skript innerhalb des Containers ausführe?

6

Eine Änderung, die ich vorgenommen habe, ist, dass Benutzer nun mehrere Schlüssel haben können (oder mehrere „Master-Schlüssel"). Das bedeutet, dass jede Integration ihren eigenen Schlüssel erhalten kann und diese separat geprüft, widerrufen oder gelöscht werden können. In deinem Fall könntest du also einen Schlüssel mit der Beschreibung „pfaffmans Einrichtungswerkzeuge" erstellen. Dann wissen die Seitenadministratoren, wofür er gedacht ist, und können ihn widerrufen oder löschen, wenn er nicht mehr benötigt wird.

Wie sich das auf einen Rake-Task übertragen lässt… bin ich mir nicht sicher. Vielleicht könnten wir einen Task haben, der so aussieht: api:get_or_create "meine Schlüsselbeschreibung" :thinking:

Würde das für deinen Fall funktionieren, @pfaffman?

7

Klar! Ich finde, das wäre einfach großartig.

8

Wie sieht es mit diesem aus?

rake api_key:get_or_create_master["Onboarding Key"]

Wenn es keine Einwände gibt, werde ich es in ein paar Stunden mergen.

10

Sieht für mich gut aus! Und mein Playbook war noch in meinem Editor offen, also habe ich mich schon festgelegt. :slight_smile:

11

Eingefügt in

16

Entschuldige, @pfaffman, aber ich muss diesen neuen Rake-Task leider in einem kommenden PR entfernen. Da wir API-Schlüssel in der Datenbank hashen werden, ist es grundsätzlich unmöglich, einen bestehenden Schlüssel wiederherzustellen.

Ich habe die get_or_create_master-Aufgabe durch eine einfachere create_master-Aufgabe ersetzt, die bedingungslos einen neuen Schlüssel erstellt. Wenn du nur einen Schlüssel haben möchtest, musst du diesen in deinem eigenen System verfolgen.

17

Ja, ich habe das irgendwie kommen sehen. Andere Systeme zeigen den API-Schlüssel nur einmal an, also…

Danke für die Vorwarnung!

18

Das kann ich nicht sofort sagen. (Warte. Wie kommt es, dass es keine schema.rb-Datei im db-Verzeichnis gibt?)

Wenn ich mehrfach rake api_key:create_master['some name'] mit demselben some name ausführe, schlägt das dann fehl? Muss dieser Name also eindeutig sein?

19

Beschreibungen müssen nicht eindeutig sein, nein. Es könnte jedoch ziemlich verwirrend werden, wenn du viele Schlüssel erstellst, die gleich aussehen.

Wir committen die Datei schema.rb nicht. Der beste Ort, um nachzuschauen, sind die Anmerkungen am Ende jeder Datei unter /app/models.

20

Warte. Was?! Seit wann? Jeder Commit in meiner aktuellen Discourse-Quelle auf meiner Festplatte enthält noch immer schema.rb. Es ist wirklich, wirklich praktisch, herausfinden zu können, nach welchem Modell man sucht. Eine einzelne Datei zu öffnen und darin zu suchen (z. B. um herauszufinden, nach welchem Modell man sucht), ist viel einfacher, als in über 200 Dateien in app/models herumzusuchen. Es gibt nicht einmal eine gute Möglichkeit, am Ende der Modelle nur das Schema mit grep zu durchsuchen.

Wenn man nicht weiß, nach welchem Modell man sucht, wie kann man es dann finden? Es gibt beispielsweise eine Reihe von Tabellen, die mit „Auth

21

Seit jeher, es steht in der .gitignore-Datei. Es wird jedoch bei der Ausführung von db:migrate generiert, weshalb es lokal vorhanden ist.

Der Tabellenname stimmt immer mit dem Namen des Modells überein, also verwende ich einfach die Dateinamen :man_shrugging:

22

Aha. Na ja, das zeigt, was ich weiß. :wink Danke für die Erklärung.

Manchmal kann ich den Namen der Tabelle/des Modells nicht erraten, daher ist es eine große Hilfe, alle Felder an einem Ort zu haben.