Auto-hospedado - redefinindo senha sem configuração de SMTP

Perguntas
1

Oi!

Estou executando n8n no GCP CloudRun com PostgreSQL. Temos alguns pares de instâncias servidas para necessidades diferentes.
Em uma das instâncias, o primeiro usuário se registrou e se tornou proprietário. Ele é o único proprietário/administrador nesta instância. Ele esqueceu sua senha e não consegue recuperá-la, porque não temos o SMTP configurado.

Qual é a maneira mais fácil de redefinir uma senha?

É seguro alterar a role para global:admin (direto no banco de dados) e depois registrar um novo proprietário que possa gerar um link de redefinição de senha?

2

Oi @rgrzesk, enquanto espera por uma resposta, aqui estão algumas coisas que podem ajudar:

[details=“Recursos sugeridos”]

Combinado automaticamente com sua pergunta.

Documentação:

Fórum:

3

Oi @rgrzesk

Aqui está uma maneira de redefinir usuários.
Isso não excluirá nenhum outro dado como fluxos de trabalho ou credenciais. Apenas usuários.

4

Oi @rgrzesk

Como você já está no ecossistema do GCP, você pode usar o Cloud Shell para se conectar diretamente à sua instância do Cloud SQL e atualizar manualmente o hash da senha. Isso elimina a necessidade de executar o n8n localmente ou gerenciar chaves de criptografia.

  1. Abra o GCP Cloud Shell do seu Google Cloud Console.
  2. Conecte-se à sua instância do Cloud SQL usando o seguinte comando:
gcloud sql connect [YOUR_INSTANCE_NAME] --user=postgres
  1. Gere um novo hash bcrypt. Como o n8n usa bcrypt, você não pode simplesmente digitar uma senha em texto simples. Você pode usar essa linha única do Python no seu Cloud Shell para gerar um hash para a senha desejada (por exemplo, NewPassword123!):
python3 -c 'import bcrypt; print(bcrypt.hashpw(b"NewPassword123!", bcrypt.gensalt()).decode())'

Copie a string resultante (começa com $2b$...).

  1. Execute a Atualização SQL. No prompt do PostgreSQL, execute o seguinte comando. Observação: user é uma palavra-chave reservada no PostgreSQL, então ela deve ser envolvida em aspas duplas.
UPDATE "user" 
SET "password" = '[PASTE_YOUR_HASH_HERE]' 
WHERE "email" = '[OWNER_EMAIL_ADDRESS]';
  1. Verifique e Saia:
SELECT email FROM "user" WHERE email = '[OWNER_EMAIL_ADDRESS]';
\q
  1. Faça login no n8n com a nova senha.
5

Oi @rgrzesk Bem-vindo!

Seu plano global:admin não funcionará — o assistente de configuração é controlado pela chave settings userManagement.isInstanceOwnerSetUp = true, não por se existe uma linha global:owner, então degradar o proprietário deixa você sem proprietário e ainda sem /setup. (global:admin também é uma função licenciada para Enterprise.)

Como você está no Postgres, apenas sobrescreva o hash bcrypt desse usuário. Uma coluna, nada mais tocado, sem redeploy:

1. Gere o hash (n8n usa bcryptjs, custo 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))\""

Use uma senha que atenda às regras do n8n (8–64 caracteres, 1 número, 1 maiúscula) ou você não conseguirá alterá-la na interface depois.

2. Conecte e atualize:

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

Duas coisas que confundem as pessoas: user é uma palavra reservada no Postgres e deve estar entre aspas duplas, e o hash deve estar entre aspas simples no seu shell ou o bash expandirá $2b/$10 e escreverá lixo.

Se essa conta tinha MFA ativada, também SET "mfaEnabled" = false, "mfaSecret" = NULL, "mfaRecoveryCodes" = NULL.

3. Faça login em uma janela anônima — n8n deriva parte do JWT de autenticação do hash de senha, então sessões antigas são invalidadas e um cookie obsoleto o rejeitará. Nenhuma reinicialização de container necessária.

Evite n8n user-management:reset aqui: você não pode fazer docker exec no Cloud Run, e apaga todas as contas de usuário e retorna a instância ao assistente de configuração. Vale a pena adicionar variáveis de ambiente SMTP em seus serviços Cloud Run depois para isso não se repetir em toda a frota.

6

Aqui usamos self-hosted no Railway. Pra conseguir resolver, incluí variáveis direto nos serviços Primary e Worker. Depois fiz o deploy e foi resolvido.

image

image
image587×167 1.57 KB

7

Tentei (na minha instância de teste) mudar outro usuário de global:owner para global:admin e funcionou. Depois de entrar na instância, vi a tela /setup novamente. Então o truque funciona bem.
A questão é - isso é seguro? Essas funções não são salvas/usadas também em outro lugar?

8

É isso que estou planejando fazer como uma solução sólida e de longo prazo :slight_smile: No momento, estou apenas tentando recuperar a instância rapidamente sem deployments adicionais.

9

Você tem razão, foi meu erro — o n8n mais recente decide se deve mostrar /setup baseado na existência de uma linha global:owner, não na chave de configurações que citei. Obrigado por testar.

Sobre segurança: existem três colunas role diferentes, e são coisas separadas. user.role é o papel da instância (aquele que você alterou). project_relation.role e shared_workflow/shared_credentials.role lidam com associação de projeto e propriedade de recursos — e são chaveados por projectId, não userId. Então nada do que você fez afeta quem é dono de qual workflow ou credencial. Essa parte está tudo bem.

A única coisa que eu mudaria: use global:member em vez de global:admin. Admin é um tipo de conta Pro/Enterprise, então na Community você colocou um usuário em um papel que a instância não pode licenciar — e a interface tende a desativar papéis não licenciados, então você pode não conseguir alterá-lo de volta sem outra escrita no BD. Member te dá a mesma tela de setup sem nenhum desse problema.

Então: faça snapshot do BD → mude o antigo proprietário para global:member → registre um proprietário descartável → Configurações → Usuários → copie o link de redefinição de senha para a conta antiga (funciona perfeitamente sem SMTP) → redefinir → recoloque os papéis → delete o usuário temporário. Não deixe duas linhas global:owner ao mesmo tempo.

De qualquer forma, vale a pena colocar N8N_EMAIL_MODE=smtp em todos os seus serviços Cloud Run — com um proprietário por instância, isso vai aparecer de novo.

10

Oi @rgrzesk
A partir do n8n 2.17.0, o proprietário da instância pode ser provisionado a partir de variáveis de ambiente, o que redefine a senha sem tocar no banco de dados. Defina estas configurações no serviço Cloud Run, usando o e-mail do proprietário existente:

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>

O n8n reaaplica estes valores à conta do proprietário existente a cada inicialização, então a revisão é ativada com a senha já alterada. Enquanto a flag está ativada, esse usuário é somente leitura na UI e as gravações de API para ele são rejeitadas, então após acessar, defina N8N_INSTANCE_OWNER_MANAGED_BY_ENV=false, os valores aplicados permanecerão em vigor e a UI será desbloqueada novamente.
Custa uma revisão, mas sem edições de função e nada para reverter no BD depois, que é a parte que escala para o resto das suas instâncias.