- Expédié
- 25 août 2026 à 00:56 UTC
- Auteur
- Kamo
- Commite
- e3daede
La création n'a vérifié l'alias au sein d'un seul fournisseur de services de sécurité, et PUT/org/-id- n'a rien vérifié - il appliquait ce qui lui était donné. Les deux étaient raisonnables alors qu'un pseudo-alias n'était résolu que comme (security-provider-id, alias) derrière un hôte du domaine de la mère. J'ai changé ça. Une organisation peut être désignée directement par son alias avec pas de fournisseur pour donner le coup de la recherche, donc une répétition rend la référence équivoque à l'échelle de la plate-forme: OrgResolutionService le refuse plutôt que d'en choisir un, qui laisse les deux organisations inaccessibles par alias. Une renommée par PUT pourrait le faire silencieusement à une orge qui était auparavant très bien. Rejete également un alias à chiffres sur les deux voies. Une référence à un chiffre se résout comme une organisation id et ne tombe jamais à la recherche d'un alias, de sorte qu'une telle alias ne pourraient jamais nommer sa propre organisation - mieux pour la refuser que de créer quelque chose d'inaméliorable. Les répétitions existantes sont laissées seules: quatre orgs partagent "acme-corp" et deux partager "kia-kaha", tous ensemencés le même jour. Un pseudonyme est une clé de locataire - il noms de dépliants de thèmes et d'hôtes de noms et de noms d'hôtes. pas quelque chose à faire unilatéralement. Le résolveur refuse déjà Des ambigus, donc rien ne résout de manière erronée entre les deux sexes. Vérifié sur un clone propre: 951 tests passent. L'arbre de travail échoue actuellement 63 tests non liés des travaux d'une autre session en vol (a PhiTenantResolver qui n'est pas encore câblé lors de ses essais).