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 logincom senha respondepassword_sign_in_disablede 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).