Auto-hébergé - réinitialiser le mot de passe sans configuration SMTP

Questions
1

Salut !

J’exécute n8n sur GCP CloudRun avec PostgreSQL. Nous avons quelques instances configurées pour différents besoins.
Sur l’une de ces instances, le premier utilisateur s’est inscrit et est devenu propriétaire. C’est le seul propriétaire/administrateur de cette instance. Il a oublié son mot de passe et ne peut pas le récupérer, car nous n’avons pas SMTP configuré.

Quel est le moyen le plus simple de réinitialiser un mot de passe ?

Est-ce que changer le rôle en global:admin directement dans la base de données est sûr et ensuite inscrire un nouveau propriétaire qui peut générer un lien de réinitialisation de mot de passe ?

2

Salut @rgrzesk, en attendant une réponse, voici quelques ressources qui pourraient t’aider :

Ressources suggérées

Automatiquement associées à ta question.

Documentation :

Forum :

@moosa, @gusgvd, @mechanizedgrowth - vous avez déjà aidé avec des problèmes similaires, pouvez-vous y jeter un coup d’œil ?

Suggéré automatiquement par le bot communautaire de n8n. C’est un pilote - veuillez partager vos retours ici.

3

Bonjour @rgrzesk

Voici une façon de réinitialiser les utilisateurs.
Cela ne supprimera aucune autre donnée comme les workflows ou les credentials. Seulement les utilisateurs.

4

Salut @rgrzesk

Puisque tu es déjà dans l’écosystème GCP, tu peux utiliser Cloud Shell pour te connecter directement à ton instance Cloud SQL et mettre à jour manuellement le hash du mot de passe. Cela t’évite d’avoir à exécuter n8n localement ou de gérer les clés de chiffrement.

  1. Ouvre GCP Cloud Shell depuis ta Google Cloud Console.
  2. Connecte-toi à ton instance Cloud SQL en utilisant la commande suivante :
gcloud sql connect [YOUR_INSTANCE_NAME] --user=postgres
  1. Génère un nouveau hash bcrypt. Puisque n8n utilise bcrypt, tu ne peux pas simplement taper un mot de passe en texte clair. Tu peux utiliser cette commande Python d’une seule ligne dans Cloud Shell pour générer un hash pour ton mot de passe souhaité (par exemple, NewPassword123!) :
python3 -c 'import bcrypt; print(bcrypt.hashpw(b"NewPassword123!", bcrypt.gensalt()).decode())'

Copie la chaîne résultante (elle commence par $2b$...).

  1. Exécute la mise à jour SQL. Dans l’invite PostgreSQL, exécute la commande suivante. Note : user est un mot-clé réservé dans PostgreSQL, il doit donc être entouré de guillemets doubles.
UPDATE "user" 
SET "password" = '[PASTE_YOUR_HASH_HERE]' 
WHERE "email" = '[OWNER_EMAIL_ADDRESS]';
  1. Vérifie et quitte :
SELECT email FROM "user" WHERE email = '[OWNER_EMAIL_ADDRESS]';
\q
  1. Connecte-toi à n8n avec le nouveau mot de passe.
5

Salut @rgrzesk Bienvenue !

Votre plan global:admin ne fonctionnera pas — l’assistant de configuration est bloqué sur la clé settings userManagement.isInstanceOwnerSetUp = true, pas sur l’existence d’une ligne global:owner, donc rétrograder le propriétaire vous laisse sans propriétaire et toujours sans /setup. (global:admin est aussi un rôle sous licence Enterprise.)

Puisque vous utilisez Postgres, écrasez simplement le hash bcrypt de cet utilisateur. Une colonne, rien d’autre touché, pas de redéploiement :

1. Générez le hash (n8n utilise bcryptjs, coût 10) :

docker run --rm node:20-alpine sh -c \
  "npm i bcryptjs --silent --prefix /tmp >/dev/null 2>&1 && \
   node -e \"console.log(require('/tmp/node_modules/bcryptjs').hashSync('YourNewPass1',10))\""

Utilisez un mot de passe qui respecte les règles de n8n (8–64 caractères, 1 chiffre, 1 majuscule) ou vous ne pourrez pas le modifier dans l’interface utilisateur par la suite.

2. Connectez-vous et mettez à jour :

UPDATE "user"
SET password = '$2b$10$...your hash...'
WHERE email = 'owner@yourdomain.com';

Deux choses qui piègent les gens : user est un mot réservé dans Postgres et doit être entre guillemets doubles, et le hash doit être entre guillemets simples dans votre shell ou bash va étendre $2b/$10 et écrire des données inutiles.

Si ce compte avait l’authentification multifacteur activée, incluez aussi SET "mfaEnabled" = false, "mfaSecret" = NULL, "mfaRecoveryCodes" = NULL.

3. Connectez-vous depuis une fenêtre de navigation privée — n8n dérive une partie du JWT d’authentification du hash de mot de passe, donc les anciennes sessions sont invalidées et un cookie obsolète vous rejettera. Aucun redémarrage de conteneur n’est nécessaire.

Évitez n8n user-management:reset ici : vous ne pouvez pas faire docker exec dans Cloud Run, et cela efface tous les comptes utilisateur et ramène l’instance à l’assistant de configuration. Cela vaut la peine d’ajouter des variables d’environnement SMTP sur vos services Cloud Run par la suite pour que cela ne se reproduise pas dans la flotte.

6

Ici, nous utilisons le self-hosted sur Railway. Pour réussir à résoudre le problème, j’ai inclus les variables directement dans les services Primary et Worker. Ensuite, j’ai fait le déploiement et c’était résolu.

image

image
image587×167 1.57 KB

7

J’ai essayé (sur mon instance de test) de changer un autre utilisateur de global:owner à global:admin et ça a fonctionné. Après être entré dans l’instance, j’ai revu l’écran /setup. Donc l’astuce marche bien.
La question est - est-ce que c’est sûr ? Ces rôles ne sont-ils pas sauvegardés/utilisés ailleurs également ?

8

C’est ce que je prévois de faire comme solution solide et à long terme :slight_smile: Pour l’instant, j’essaie simplement de récupérer l’instance rapidement sans déploiements supplémentaires.

9

Tu as raison, c’est ma faute — la nouvelle version de n8n décide d’afficher /setup en fonction de l’existence d’une ligne global:owner, pas de la clé de paramètres que j’ai citée. Merci de l’avoir testé.

Sur la sécurité : il y a trois colonnes role différentes, et ce sont des choses distinctes. user.role est le rôle de l’instance (celui que tu as modifié). project_relation.role et shared_workflow/shared_credentials.role gèrent l’appartenance au projet et la propriété des ressources — et ils sont indexés sur projectId, pas userId. Donc rien de ce que tu as fait ne touche à la propriété des workflows ou des credentials. Cette partie va bien.

La seule chose que je changerais : utilise global:member au lieu de global:admin. Admin est un type de compte Pro/Enterprise, donc sur Community tu as placé un utilisateur dans un rôle que l’instance ne peut pas licencier — et l’interface a tendance à désactiver les rôles non licenciés, donc tu pourrais ne pas pouvoir le changer sans une autre écriture en DB. Member te donne le même écran de configuration sans tous ces problèmes.

Donc : snapshot la DB → définis l’ancien propriétaire sur global:member → enregistre un propriétaire jetable → Paramètres → Utilisateurs → copie le lien de réinitialisation du mot de passe pour l’ancien compte (fonctionne très bien sans SMTP) → réinitialise → remet les rôles en place → supprime l’utilisateur temporaire. Ne laisse pas deux lignes global:owner à la fois.

De toute façon, ça vaut le coup de mettre N8N_EMAIL_MODE=smtp sur tous tes services Cloud Run — avec un propriétaire par instance, ça va réapparaître.

10

Bonjour @rgrzesk
À partir de n8n 2.17.0, le propriétaire de l’instance peut être provisionné à partir de variables d’environnement, ce qui réinitialise le mot de passe sans toucher à la base de données du tout. Définissez-les sur le service Cloud Run, en utilisant l’e-mail du propriétaire existant :

N8N_INSTANCE_OWNER_MANAGED_BY_ENV=true
N8N_INSTANCE_OWNER_EMAIL=owner@yourdomain.com
N8N_INSTANCE_OWNER_FIRST_NAME=Firstname
N8N_INSTANCE_OWNER_LAST_NAME=Lastname
N8N_INSTANCE_OWNER_PASSWORD_HASH=<bcrypt hash>

n8n réapplique ces valeurs au compte propriétaire existant à chaque démarrage, de sorte que la révision démarre avec le mot de passe déjà modifié. Tant que l’indicateur est activé, cet utilisateur est en lecture seule dans l’interface utilisateur et les écritures API pour lui sont rejetées. Une fois connecté, définissez N8N_INSTANCE_OWNER_MANAGED_BY_ENV=false, les valeurs qu’il a appliquées restent en place et l’interface utilisateur se déverrouille à nouveau.
Cela coûte une révision, mais pas de modifications de rôles et rien à annuler dans la base de données ensuite, ce qui est la partie qui s’étend sur le reste de vos instances.