- Navios
- 25 de agosto de 2026 às 00:56 UTC
- Autor
- Kamo
- Enviar
- e3daede
A criação verificou o apelido apenas dentro de um provedor de segurança, e PUT /org/{id} não verificou nada — aplicou o que quer que tenha sido dado. Ambos eram razoáveis, enquanto um pseudónimo só era resolvido como (security provider id, alias) por trás de uma máquina <alias>.<domínio-mãe>. ?org= mudou isso. Uma organização pode ser nomeada diretamente pelo seu apelido com nenhum fornecedor que explore a pesquisa, por isso uma repetição torna a referência ambígua plataforma: OrgResolutionService recusa-o em vez de escolher um, O que deixa ambas as organizações inalcançáveis pelo nome falso. A renomear através de PUT poderia fazer isso silenciosamente a uma org que antes estava bem. Também rejeita um alias de todos os dígitos em ambos os caminhos. Um dígito de referência resolve como uma organização id e nunca cai para o alias procurar, de modo que alias nunca poderia nomear sua própria organização — melhor para recusá-la do que para criar algo inatingível. As repetições existentes são deixadas em paz: quatro orgs compartilham "acme-corp" e dois compartilhar "kia-kaha", todos semeados no mesmo dia. Um pseudônimo é uma chave de inquilino — ele nomes pastas de temas e < alias>.<domínio> hosts — assim renomear as pastas ao vivo é Não há nada a fazer unilateralmente. O resolvedor já recusa o Ambíguos, portanto, nada resolve de forma errada entretanto. Verificado em um clone limpo: 951 testes passam. A árvore de trabalho falhou de momento 63 testes não relacionados do trabalho PHI de outra sessão em voo (a PhiTenantResolver que ainda não está conectado em seus testes).