Authorization header non fonctionnel sur n8n Cloud - erreur 401 mais fonctionne correctement avec curl

Questions
1

Décrivez le problème/l’erreur/la question

Le nœud HTTP Request envoie une erreur 401 Unauthorized à l’API Infobip WhatsApp, malgré une en-tête Authorization configurée correctement. La même requête fonctionne parfaitement via curl depuis le terminal avec la clé API identique, les en-têtes et le corps identiques.

Le journal d’exécution affiche « authorization » : « hidden » — la valeur de l’en-tête semble être effacée ou corrompue avant d’être envoyée à l’API.

J’ai essayé : Header Auth credential, Custom Auth credential avec JSON, en-tête manuel avec Auth défini sur None, mode expression pour la valeur d’en-tête — tous retournent 401. curl avec la même clé depuis la même machine retourne 200 à chaque fois.

Ceci semble être le même bogue de réinitialisation des identifiants __n8n_BLANK_VALUE signalé dans les problèmes GitHub #12596, #14615, #17655.

Quel est le message d’erreur (le cas échéant) ?

401 - "{"requestError":{"serviceException":{"messageId":"UNAUTHORIZED","text":"Invalid login details"}}}"

Veuillez partager votre workflow

les nouveaux utilisateurs ne peuvent pas télécharger de pièces jointes :frowning:

Partagez la sortie retournée par le dernier nœud

{
"headers": {
"authorization": "hidden",
"content-type": "application/json",
"accept": "application/json,text/html,application/xhtml+xml,application/xml,text/;q=0.9, image/;q=0.8, /;q=0.7"
},
"method": "POST",
"uri": "``https://3v16p1.api.infobip.com/whatsapp/1/message/text``",
"json": false
}

Informations sur votre configuration n8n

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

@Danijel_Domjanovic ce authorization: hidden dans le log ne prouve pas que la valeur a été effacée — n8n masque les valeurs des en-têtes dans la vue d’exécution, donc ce pourrait être juste une suppression. la seule façon de savoir ce qui sort réellement est de l’afficher : pointez la requête http vers une url webhook.site et lisez l’en-tête authorization qu’elle reçoit. vide ou __n8n_BLANK_VALUE = ouais c’est le bug que tu as trouvé. valeur complète et correcte = ce n’est pas n8n qui le supprime, vérife le préfixe de l’App la clé infobips a besoin est intacte.

3

c’était une bonne idée, j’ai vérifié ce qui arrivait au webhook, tout va bien du côté de n8n. C’est probablement une sorte de politique de sécurité interne d’Infobips, car j’ai testé de l’extérieur de notre réseau et ça a échoué. Merci pour l’aide :slight_smile:

4

@Danijel_Domjanovic ouais c’est une liste blanche d’adresses IP côté Infobip dans ce cas. n8n cloud utilise des adresses IP rotatives de centres de données, donc tu peux pas juste les ajouter à la liste blanche. La solution la plus simple est de router l’appel via un proxy avec une adresse IP statique que tu contrôles (un petit VPS) et d’ajouter cette seule adresse IP à la liste blanche dans Infobip.

5

Bienvenue @Danijel_Domjanovic!

La liste d’adresses IP autorisées est une cause possible, mais la valeur « hidden » dans le journal d’exécution vaut la peine d’être examinée séparément - elle pointe vers un problème de valeur vierge d’authentification, pas seulement un filtrage IP. Moyen rapide d’écarter cette hypothèse : basculez le nœud HTTP Request pour utiliser un en-tête Authorization codé en dur (réglez Auth sur None, ajoutez l’en-tête manuellement dans l’onglet Headers avec le jeton saisi directement, pas à partir d’une authentification). Si cela retourne 200, c’est l’authentification elle-même qui pose problème, pas l’IP. Vous pouvez ensuite recréer l’authentification à partir de zéro plutôt que d’éditer celle existante, car le bug __n8n_BLANK_VALUE survit souvent aux modifications mais pas à la recréation.