Ronne AI Marketplace 0.5.0

Novidades

• Admin › Settings é dividido em abas: Usage, Plugin feeds, uma nova aba Authentication, em que o root decide como as pessoas fazem login, e uma nova aba Privacy.
• O root conecta o provedor de identidade da empresa pelo navegador, com instruções passo a passo para cada um: Google Workspace, Microsoft Entra ID, Okta, Keycloak, authentik, Auth0 ou qualquer outro provedor OpenID Connect. Uma conta é vinculada pelo e-mail verificado dela, ou criada no primeiro login para os domínios que o root escolher, com o papel user. Um Test sign-in mostra o que o provedor devolve e não muda nada.
• Os grupos do provedor podem ser mapeados para papéis nos espaços de trabalho, para que os membros acompanhem o diretório da empresa. Uma política de senha e o rmk-server disable-sso fazem com que um provedor quebrado não consiga trancar todo mundo do lado de fora.
• As pessoas podem acrescentar uma segunda etapa ao login com senha: um código de um app autenticador, com códigos de backup para o caso de perderem o celular. O root decide se ela é opcional, obrigatória para todos ou obrigatória para quem é root ou moderador.
• O rmk login --web é para quem faz login com um provedor ou com uma segunda etapa: o rmk mostra um código curto e um endereço, você o aprova no navegador em que fez login, e ele recebe um token de acesso pessoal. A configuração do MCP também o usa.
• O provedor de identidade pode criar, atualizar e remover contas sozinho pelo SCIM, com um token para cada provedor, e manter os membros dos espaços de trabalho em sincronia com os grupos dele. Quando alguém é removido, a conta da pessoa é desativada e as sessões e os tokens dela são revogados.
• O root define por quanto tempo os endereços IP ficam no log de auditoria, nas sessões e nas aprovações de rmk login, 90 dias por padrão. O servidor faz a limpeza do que é mais antigo em um agendamento, e o rmk-server purge a faz pelo cron.
• O root pode apagar uma pessoa. O e-mail, o nome e as credenciais dela somem, e o que ela fez continua sob o pseudônimo deleted-user-<id>, então o histórico de um item e o log de auditoria continuam fazendo sentido. Não dá para desfazer.
• O root abre uma página para cada pessoa em Admin › Users, com o papel, o status e o último login dela, e as ações: mudar o papel, desativar ou ativar, redefinir a senha ou a segunda etapa, baixar os dados e apagar a pessoa. A lista mostra o último login e um botão para copiar cada e-mail.
• Na página Account, cada pessoa baixa um único arquivo JSON com o que a instância guarda sobre ela: a conta, os nomes dos tokens, as submissões, os comentários e os eventos de auditoria. O root pode gerá-lo para quem pediu.