Les variables d'environnement bloquées dans le nœud Airtable sur n8n 2.19.5 auto-hébergé - comportement attendu ou mauvaise configuration ?

Questions
1

Bonjour à tous,
J’exécute n8n auto-hébergé v2.19.5 sur un VPS en utilisant Docker Compose. J’essaie de créer un workflow de génération de leads prêt pour la production et j’ai rencontré quelque chose de confus concernant les variables d’environnement à l’intérieur des paramètres de nœud.

Problème

Quand j’essaie de référencer une variable d’environnement à l’intérieur du nœud Airtable (Base → By ID), comme ceci :

Code

{{$env.AIRTABLE_BASE_ID}}

…j’obtiens cette erreur directement dans l’interface :

Code

[ERROR: access to env vars denied]

Si je supprime les crochets d’expression et que je tape simplement du texte brut, l’erreur disparaît.
Si je codifie en dur l’ID de la base, aucune erreur.
Si j’utilise $env.AIRTABLE_BASE_ID à l’intérieur d’un nœud Function, cela fonctionne très bien.

Il semble donc que les variables d’environnement soient disponibles pour l’exécution, mais bloquées dans les expressions de l’interface.

Contexte

  • n8n auto-hébergé 2.19.5

  • Déploiement Docker Compose

  • Variables d’environnement définies dans docker-compose.yml

  • Les identifiants personnels d’accès Airtable fonctionnent

  • Le menu déroulant « From List » génère une erreur 403 (attendue en raison des autorisations Airtable)

  • Le seul obstacle est l’accès aux variables d’environnement à l’intérieur des paramètres de nœud

Questions

  1. Est-ce un comportement attendu pour la version gratuite auto-hébergée de n8n 2.x ?

  2. Les variables d’environnement sont-elles intentionnellement bloquées dans les expressions de l’interface sauf avec n8n Pro ?

  3. Quel est le contournement recommandé pour les utilisateurs auto-hébergés qui souhaitent des workflows réutilisables (par exemple, stocker l’ID de la base dans les identifiants) ?

  4. Existe-t-il une documentation officielle expliquant cette restriction ?

Objectif

Je souhaite créer des workflows réutilisables sans codifier en dur les ID de base, mais j’essaie de comprendre si cette limitation est volontaire ou si j’ai mal configuré quelque chose.

Merci d’avance à tous ceux qui peuvent clarifier le fonctionnement des variables d’environnement dans les paramètres de nœud sur la version auto-hébergée 2.x

Informations sur votre configuration n8n

  • Version n8n : v2.19.5
  • Base de données (par défaut : SQLite) :
  • Paramètre EXECUTIONS_PROCESS de n8n (par défaut : own, main) :
  • Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) : Docker Compose
  • Système d’exploitation : Ubuntu
3

Bonjour @NE_automation

Oui

Non

Voici

4

Merci pour les liens ! J’ai lu cette doc et j’ai aussi consulté ce problème. Il semble que la modification affecte principalement l’accès aux variables d’environnement à l’intérieur des nœuds Code, et peut être basculée avec N8N_BLOCK_ENV_ACCESS_IN_NODE. Dans mon cas, $env fonctionne bien dans les nœuds Code - le blocage n’est pas le problème. Le problème est que les variables d’environnement sont refusées spécifiquement dans les expressions de paramètres de nœud (par exemple, Airtable Base ID), où j’obtiens [ERROR: access to env vars denied] même si la variable existe dans le conteneur. D’après ce que j’en déduis, cela semble être une restriction distincte dans le système d’expressions de l’interface 2.x. Je cherche juste à confirmer s’il s’agit d’un comportement attendu pour la version auto-hébergée gratuite.

5

bonjour @NE_automation
c’est un comportement de sécurité de n8n 2.x
utilisez N8N_BLOCK_ENV_ACCESS_IN_NODE=false et redémarrez votre conteneur

6

Merci pour la suggestion ! J’ai déjà testé N8N_BLOCK_ENV_ACCESS_IN_NODE=false et $env fonctionne correctement dans les nœuds Code. Le problème auquel je suis confronté est différent - les variables d’environnement sont bloquées spécifiquement dans les expressions des paramètres de nœud (comme les champs « Table » et « Base » d’Airtable), où j’obtiens un message access to env vars denied même si la variable existe et que les nœuds Code peuvent la lire. Je n’ai rien vu dans la documentation des modifications majeures de la version 2.0 à propos des variables d’environnement restreintes dans les expressions UI, donc j’essaie de confirmer si c’est un comportement attendu dans la version 2.x auto-hébergée.

7

Merci à tous pour votre aide ! J’ai trouvé la solution - le problème venait du fait que j’avais ajouté +bases sous Access mais j’avais oublié d’activer schema.bases:read sous Scopes. Une fois que j’ai ajouté ce scope, tout a fonctionné. Merci à tous ceux qui ont participé.

8

Marquez votre réponse comme solution afin que les autres membres puissent résoudre leurs questions plus facilement. Cheers :tada: