comfyui-qwen: COMFYUI_AUTH_TOKEN et COMFYUI_BEARER_TOKEN resolvent vide (deux producteurs du .env, jeux de cles divergents) #14382

Constat

Le .env du service comfyui-qwen a deux producteurs qui n'ecrivent pas le meme jeu de cles, et c'est le dernier qui a tourne qui decide ce que le conteneur recoit :

Etat mesure le 2026-09-02 (noms de cles uniquement, aucune valeur lue ni transmise) :

• docker-configurations/services/comfyui-qwen/.env : aucune cle d'auth ComfyUI. Seuls CIVITAI_TOKEN et HF_TOKEN sont presents. COMFYUI_RAW_TOKEN absent, COMFYUI_BEARER_TOKEN absent.
• docker-configurations/services/comfyui-video/.env : COMFYUI_VIDEO_TOKEN present.

Or les composes interpolent :

• comfyui-qwen/docker-compose.yml:75 -- COMFYUI_BEARER_TOKEN=${COMFYUI_BEARER_TOKEN} -> resout vide
• comfyui-qwen/docker-compose.yml:123 -- COMFYUI_AUTH_TOKEN=${COMFYUI_RAW_TOKEN} -> resout vide
• comfyui-video/docker-compose.yml:115 -- COMFYUI_AUTH_TOKEN=${COMFYUI_VIDEO_TOKEN} -> resout

L'asymetrie est reelle : video est cable, qwen ne l'est pas.

Portee reelle : latent, pas une panne

Le compose qwen bind-monte le fichier de token (L44-45) :

source: ../../../.secrets/qwen-api-user.token
target: /workspace/ComfyUI/.secrets/qwen-api-user.token

et scripts/secrets/render_envs.py L160-180 documente que c'est la voie d'auth : le middleware ComfyUI-Login lit ce fichier directement, la forme variable d'environnement etant un fallback cote notebook.

Consequence : les deux variables vides degradent le fallback, elles ne coupent pas le service. Signature attendue si le cas se presente : l'UI ComfyUI repond normalement, mais un notebook qui lit COMFYUI_AUTH_TOKEN part avec une chaine vide et se prend un 401 — un echec qui ne ressemble pas a un probleme d'auth du service, puisque le service, lui, va bien.

C'est precisement le genre de defaut qui ne se manifeste qu'a distance de sa cause, d'ou l'issue plutot qu'un correctif immediat.

Ce qui n'est pas tranche ici

Deux correctifs sont possibles et ils n'ont pas la meme intention :

1. Cabler : faire propager COMFYUI_RAW_TOKEN / COMFYUI_BEARER_TOKEN par render_envs.py depuis master.env. Retablit le fallback, mais fait vivre un token brut dans un .env de service la ou seule la forme hashee y transite aujourd'hui — un arbitrage de posture, pas un detail.
2. Debrancher : cesser d'interpoler dans le compose des variables que rien ne definit, et assumer le bind-mount comme unique voie. Plus propre, mais casse tout consommateur qui compte encore sur la variable.

Le choix demande de redemarrer la stack pour etre valide (regle connue : le hash bcrypt de ComfyUI-Login n'est relu qu'au restart, cf docs/genai/secrets-management.md). Je n'ai donc rien modifie : on ne touche pas a du plumbing d'auth a l'aveugle.

Reproduction

# noms de cles seulement, jamais les valeurs
grep -oE '^[A-Za-z_][A-Za-z0-9_]*=' docker-configurations/services/comfyui-qwen/.env \
  | tr -d '=' | grep -i 'token\|auth'
grep -rn 'COMFYUI_\(RAW\|AUTH\|BEARER\)_TOKEN' docker-configurations/services/*/docker-compose.yml
grep -c 'RAW_TOKEN' scripts/secrets/render_envs.py    # -> 0

Origine

Mesure faite en repondant a une question de myia-po-2026:CoursIA-2 sur la comparaison de deux tokens ComfyUI. Elle a produit au passage un rappel qui vaut d'etre ecrit : comparer deux empreintes de valeurs bcrypt ne peut pas decider si le secret sous-jacent est le meme — $2b$12$ porte 22 caracteres de sel aleatoire, donc le meme mot de passe hashe deux fois donne deux chaines differentes. Le test qui tranche sans faire circuler de secret est bcrypt.checkpw(raw_local, hash_distant), execute par le detenteur du brut, qui ne renvoie qu'un booleen.

Aucune valeur de secret n'a ete lue, imprimee ni transmise pour produire cette issue.