Je cherche un moyen de déterminer dynamiquement quelle credential stockée un nœud utilise au moment de l’exécution, en fonction des données du workflow (par exemple, un champ entrant comme « cluster » ou « environment »), plutôt que d’avoir la credential fixée par nœud.
Pour être clair, je ne parle pas de transmettre une clé API/secret brute comme valeur d’expression dans le workflow. Je veux spécifiquement référencer et basculer entre différentes credentials n8n stockées en fonction de l’exécution, afin que le secret réel reste géré dans le credential store plutôt que d’être exposé dans le workflow lui-même.
Mon cas d’usage : nous avons un workflow qui trie les alertes provenant de plusieurs clusters Elastic, chacun avec sa propre credential stockée. Nous aimerions qu’un seul nœud sélectionne la credential appropriée par exécution en fonction du cluster dont proviennent les données, au lieu de dupliquer des nœuds ou des workflows par cluster.
Est-ce actuellement possible dans n8n d’une quelconque manière (via une expression sur le champ credential, une sorte de logique de sélection de credential, ou un autre mécanisme), ou cela n’est-il pas supporté aujourd’hui?
Il n’existe pas d’option dynamique pour sélectionner une credential. Cependant, vous pouvez créer un sous-workflow qui déclenchera un nœud avec une credential prédéfinie basée sur les critères que vous choisissez.
Par exemple, j’ai plusieurs nœuds HTTP avec leurs propres credentials qui gèrent les opérations automatiquement en fonction de l’entrée
Bonjour @ntoll01
La partie sélectionnable peut être le sous-workflow plutôt que la credential. Un workflow par cluster, chacun contenant un seul nœud avec la credential de ce cluster, appelé à partir du workflow de triage avec Execute Sub-workflow défini sur Source: Database et une expression dans le champ Workflow ID qui mappe le nom de cluster entrant à son ID. L’ajout d’un cluster est alors un nouveau workflow plus une ligne dans cette map, sans rien qui ne grandisse du côté du triage.
Chacun de ces sous-workflows doit avoir son paramètre « This workflow can be called by » configuré pour autoriser l’appelant, sinon l’appel échoue à l’exécution.
La version native de ce que vous avez demandé est une demande de fonctionnalité ouverte, qui mérite un upvote :
Non pris en charge nativement. Vous ne pouvez pas mettre une expression sur le sélecteur d’identifiants, et la demande de fonctionnalité est ouverte depuis 2021. Les nœuds natifs verrouillent l’identifiant au moment de la conception.
Ce que vous pouvez faire à la place :
Si vous êtes en Enterprise, regardez les identifiants dynamiques et les secrets externes. C’est la version appropriée de ce que vous décrivez, les identifiants résolus à l’exécution plutôt que fixés sur le nœud.
Pour Elastic spécifiquement, il y a une option plus simple. Utilisez un nœud HTTP Request à la place du nœud Elastic, stockez le point de terminaison et la clé de chaque cluster dans une recherche, et définissez l’en-tête d’authentification par expression. Vous perdez la commodité du nœud, mais vous obtenez un nœud gérant tous les clusters. Le compromis est que la clé se trouve dans les données d’exécution plutôt que dans le magasin d’identifiants, ce qui peut ne pas être acceptable compte tenu de ce que vous avez dit sur la gestion des secrets.
Êtes-vous en Enterprise ? C’est ce qui détermine laquelle de ces options vous est réellement ouverte.
@barn4k J’ai envisagé plusieurs nœuds HTTP, mais dans notre situation, nous avons 5 nœuds HTTP pour créer le dossier, ajouter des alertes, définir le statut, etc. Pour 4 clusters, c’est déjà 20 nœuds HTTP.
@Lopez nous sommes sur une licence professionnelle, donc malheureusement pas de possibilité d’utiliser External Secrets. J’ai examiné la solution de contournement et elle semble prometteuse, je vais creuser davantage.
@Anshul_Namdev ce sera probablement notre première solution de contournement, en utilisant un workflow routeur avec des sous-workflows par client.
@n8n y a-t-il actuellement un défi technique pour placer une expression sur le sélecteur d’identifiants ? Toutes ces solutions de contournement semblent beaucoup plus complexes qu’un problème qui pourrait simplement être résolu avec une expression, et la scalabilité de nos appels API serait beaucoup meilleure avec cela.
