- Se descapó
- 25 de agosto de 2026 a las 0:56 UTC
- Autor
- Kamo
- Compromit
- e3daede
La creación revisó el alias sólo dentro de un proveedor de seguridad, y PUT /org/-id-no revisó nada en absoluto. Se aplicó lo que se le dio. Ambos eran razonables, mientras que un alias sólo se resolvió como (security.provider.id, alias) detrás de un host de .UU...parentdomain. ?org= cambió eso. Una organización puede ser nombrada directamente por su alias con ningún proveedor para ampliar la mirada, por lo que una repetición hace la referencia ambigua plataforma en todo: OrgResolutionService lo rechaza en lugar de elegir uno, que deja a las organizaciones BOTH inalcanzable por alias. Un cambio de nombre a través de PUT podría hacer eso en silencio a una org que antes estaba bien. También rechaza un alias de todos los dígitos en ambos caminos. Una referencia de un dígito se resuelve como una organización id y nunca cae a través de la mirada alias, así que tal alias nunca podría nombrar a su propia organización mejor para rechazarlo que crear algo inalcanzable. Las repeticiones existentes se dejan solas: cuatro orgs comparten "acme-corp" y dos compartir "kia-kaha", todo semilla el mismo día. Un alias es una llave de inquilino. nombra carpetas temáticas y hosts de "alias"..domain, por lo que cambiar el nombre en vivo es no algo que hacer unilateralmente. El solucionador ya rechaza el Unos ambiguos, así que nada se resuelve mal mientras tanto. Verificado en un clon limpio: Pasan las pruebas 951. El árbol de trabajo falla actualmente 63 pruebas no relacionadas de la labor de PHI en vuelo de otra sesión (a PhiTenantResolver aún no está conectado en sus pruebas).