Pular para o conteúdo
Documentação: Login com senha e bloqueio

Login com senha e bloqueio

Quem ainda pode entrar com senha depois que um provedor está ativo, e como o root volta a entrar quando um provedor quebra ou deixa de ser confiável.

Descreve o Ronne AI Marketplace 0.4.0. Traduzida do inglês.

Login com senha

Em Admin › Settings › Authentication › Password sign-in, o root escolhe quem ainda pode fazer login com senha:

  • Everyone (o padrão): a página de login tem o formulário de senha e, embaixo dele, os botões dos provedores.
  • Root only: os botões vêm primeiro, e o formulário de senha fica atrás de Use your password (root). Quem não for root e digitar a senha recebe o habitual "Email or password is wrong", e o rmk login com senha responde password_sign_in_disabled e continua no navegador (Fazer login pelo navegador).

Root only só pode ser escolhido enquanto um provedor estiver ativo e tiver passado no teste, e pede que você confirme quantas pessoas perdem o login com senha. Ele só vale enquanto um provedor estiver ativo: com todos os provedores desativados, todos podem usar a senha de novo.

Bloqueio e provedores com falha

O root sempre pode fazer login com senha, seja qual for a escolha, então um provedor quebrado não consegue trancar todo mundo do lado de fora. Quando um provedor quebrar ou não for mais confiável, rode disable-sso no servidor:

  • Docker: docker compose exec web pnpm run disable-sso
  • Um serviço no Linux ou macOS: sudo rmk-server disable-sso
  • npm: rmk-server disable-sso; um clone: pnpm run disable-sso

O comando desativa todos os provedores, e o SCIM deles, e deixa todo mundo fazer login com senha de novo, depois de perguntar (--yes não pergunta). Ninguém é desconectado, e os provedores mantêm as configurações, os vínculos, os tokens SCIM e as participações em grupos, para serem ativados de novo depois de corrigidos. Quem só faz login por um provedor não consegue entrar até um ser ativado de novo, ou até o root definir uma senha para essa pessoa em Usuários.

O rotate-secret criptografa de novo os client secrets dos provedores com o novo AUTH_SECRET, então eles continuam funcionando; os tokens SCIM são guardados como hashes, então não são afetados. O revoke-access --everyone revoga os tokens SCIM junto com os tokens de acesso de todos: gere novos depois. Um backup restaurado com outro AUTH_SECRET não consegue ler os client secrets: o provedor mostra Failing com "Enter the client secret again" (Restaurar).