Je construis une application d’automatisation de factures avec :
N8n version 2.18.5
MySql version 8.0.46
React Vite version 18.3.1 (Frontend)
Pour l’authentification, mon workflow de connexion génère :
Jeton d’accès (renvoyé dans le corps de la réponse)
Jeton de rafraîchissement (renvoyé sous forme de cookie HttpOnly)
Jeton CSRF (renvoyé sous forme de cookie)
Le corps de la réponse ressemble à :
{
“success”: true,
“access_token”: “…”,
“expires_in”: 1200
}
Initialement, j’ai essayé d’ajouter deux en-têtes de réponse portant le même nom :
Cependant, seul le deuxième cookie atteint le frontend ; le premier est omis.
Comme solution de contournement, je retourne actuellement la valeur d’en-tête sous forme de tableau :
{{
[
‘refresh_token=’ + $(‘Code:Combine Tokens’).item.json.refresh_token +
‘; HttpOnly; Secure; SameSite=Lax; Path=/refresh-token; Max-Age=1200’,
‘csrf_token=’ + $(‘Code:Combine Tokens’).item.json.csrf_token +
‘; Secure; SameSite=Lax; Path=/; Max-Age=1200’
]
}}
Mes questions sont :
Retourner un tableau pour l’en-tête de réponse Set-Cookie est-il l’approche recommandée dans le nœud Respond to Webhook ?
N8n convertit-il en interne ceci en plusieurs en-têtes Set-Cookie, ou existe-t-il une meilleure façon d’envoyer plusieurs cookies ?
Y a-t-il des problèmes de compatibilité avec les navigateurs ou les proxies lors de l’utilisation de cette approche ?
Y a-t-il une prise en charge prévue (ou une configuration existante) pour envoyer plusieurs en-têtes portant le même nom directement ?
Bonjour @lekha_pm Bienvenue !
Le nœud Respond to Webhook ne peut pas émettre deux lignes Set-Cookie. Il aplatit les Response Headers en un objet simple indexé par le nom d’en-tête et convertit chaque valeur en chaîne, donc deux entrées set-cookie s’écrasent mutuellement (c’est pourquoi seule la deuxième vous est parvenue), et une valeur de tableau est jointe avec des virgules en un seul en-tête. Un Set-Cookie séparé par des virgules n’est pas valide selon la RFC 6265 et se casse dès qu’une valeur contient une virgule (une date Expires en contient une), donc les navigateurs et les proxies ne vont pas extraire les deux cookies de manière fiable. Le tableau n’est pas une approche recommandée, il ne survit ici que parce que vos deux valeurs se trouvent être exemptes de virgules.
La solution propre est d’arrêter d’essayer d’envoyer deux cookies HttpOnly. Seul refresh_token doit être HttpOnly, donc envoyez celui-ci comme le seul Set-Cookie et retournez csrf_token dans le corps JSON :
Dans le modèle de double soumission, le cookie CSRF est censé être lisible par JS de toute façon, donc définissez-le côté client à partir de cette valeur de corps dans votre application React. Cela laisse n8n envoyer un cookie, que le nœud gère correctement.
Si les deux valeurs doivent vraiment être des cookies HttpOnly définis par le serveur, placez un proxy inverse (nginx) devant n8n et ajoutez-y le deuxième Set-Cookie, car le nœud lui-même ne peut pas en envoyer deux.
n’est pas conforme à la spécification des cookies. Les navigateurs traitent la partie après la virgule comme une nouvelle valeur d’en-tête, souvent l’ignorant. De plus, lorsqu’un cookie inclut un attribut Expires=Wed, 05 Oct 2024 14:48:00 GMT (qui contient lui-même une virgule), l’en-tête entier devient malformé et les deux cookies peuvent être supprimés. Certains proxies réécrivent également ou suppriment les en-têtes Set‑Cookie malformés, ce qui entraîne un comportement incohérent entre les environnements.
Pour le moment, n8n ne fournit pas de moyen intégré pour émettre des noms d’en-tête dupliqués à partir du nœud Respond to Webhook. Cette demande de fonctionnalité a été discutée dans la communauté, mais le modèle recommandé est de garder la réponse simple (un seul cookie) et de gérer les cookies supplémentaires en dehors de n8n (par exemple, via un script front-end ou un reverse-proxy).