Okay, ich arbeite an einem benutzerdefinierten Node mit massenhaft Konfigurationsoptionen. Nicht besonders komplex, nur aufwändig. Eine der Sachen, über die ich mir den Kopf zerbrochen habe, ist die Verwaltung von Credentials – grundsätzlich vier verschiedene Optionen in zwei verschiedenen Sets.
Die erste Wahl für Benutzer ist, ob die Credentials “hardcodiert” als Credential-Objekt (basierend auf einer .credentials.ts-Definition) oder dynamisch in den Node-Properties (definiert in der .node.ts-Datei) bereitgestellt werden, für Fälle, in denen eine einzelne Pipeline in einer Multi-Site-Umgebung verwendet wird (wodurch die Credentials dynamisch von einer sicheren Quelle übergeben werden können; das “Woher” liegt außerhalb meines Einflussbereichs, daher schien dies der vernünftigste Ansatz zu sein).
Die zweite Wahl ist, ob Benutzer ein API-Token direkt bereitstellen oder ein Passwort bereitstellen, das zum Abrufen eines Tokens verwendet wird. Wenn der Benutzer ein Token bereitstellt, wird es einfach kodiert und in einen Auth-Header für jede beliebige Anfrage eingefügt – kein Problem. Aber wenn sie ein Passwort bereitstellen, muss der Node zunächst eine „spezielle
@robby.emslie du bist nicht verrückt, hier ist meine Vermutung: Das Hinzufügen der Password-Option hat einen getNodeParameter-Aufruf hinzugefügt (oder einen displayOptions-Auth-Selector, der ein Feld ausblendet), und getNodeParameter wirft „Could not get parameter
Die beiden obigen Antworten decken den wahrscheinlichen Bug ab. Ich würde danach eine Schutzmaßnahme hinzufügen: Sowohl gespeicherte als auch inline eingegebene Anmeldedaten sollten sich in das gleiche normalisierte Verbindungsobjekt auflösen, mit entfernten leeren Strings, aufgezeichnetem Authentifizierungsmodus und ohne rohe Secrets in Logs. Dann validiere nur dieses Objekt. Das macht das Debuggen einfacher, ohne Token preiszugeben.
Hier ist irgendwas richtig schiefgelaufen – haha! Ich werde das heute Nachmittag wahrscheinlich komplett neu aufbauen müssen. Irgendwo habe ich einen Fehler gemacht. Aber ich bin neugierig auf den eingebauten Hook – ich schaue mir Metabase und Auth0Management als Template an. Ich habe das ursprünglich versucht zu verwenden, und ich glaube, es hat fast funktioniert, aber dann habe ich etwas kaputt gemacht, als ich die Option für dynamische Authentifizierung eingefügt habe.
Das ist aber super hilfreich. Danke dir vielmals. Ich glaube, das Problem passiert irgendwo bei getCredentials(), aber mir ist klar, dass es an diesem Punkt mehr Arbeit ist, herauszufinden, was falsch läuft, als mein Repo auf meine letzte funktionierende Konfiguration zurückzusetzen.
Ich wollte nochmal auf diese Sache zurückkommen und dir danken. Der Vorschlag, mir Metabase und Auth0Management anzuschauen, war ein Rettungsanker.
Ich denke, das löst das Problem, das ich hatte, aber ich werde die passwortbasierte Authentifizierung aus dynamicCredentials rausnehmen, glaube ich. Mir ist das wie ein Sicherheitsleck, das nur auf den richtigen Moment wartet. Es funktioniert schon, aber ich werde es auskommentieren und wenn jemand auf der anderen Seite es aktivieren möchte, ist das ihre Verantwortung. lol
lol