Follow-up to #282 / #281 (role stores) and elsa-workflows/elsa-core#8615. Those fix roles only. On shared-store multi-tenant hosts, the identity user and application stores still have store-wide uniqueness problems.
Mongo
| Collection |
Index |
Effect |
User |
Name_1 unique (store-wide) |
Two tenants can't each have a user with the same name. That includes the default seeded admin user, so the second tenant's admin seeding fails. |
Application |
Name_1 unique (store-wide) |
Two tenants can't each have an application with the same display name. |
Application |
ClientId_1 unique (store-wide) |
This should probably stay global. The client is resolved from the incoming credential before the tenant is known, so a ClientId lookup can't apply a tenant filter. A compound (TenantId, ClientId) index would let two tenants reuse a client id, and resolution would become ambiguous or wrong. Keep it global unless the token/API-key pipeline is changed to resolve the tenant first. |
Proposed: compound unique indexes (TenantId, Name) for User and Application.Name, using the same idempotent drop-old-and-create-new migration pattern as #281. Leave the decision on ClientId open, with a store-global default.
Dapper
Users / Applications have no unique index on Name or ClientId (only the Id primary key). Same-tenant duplicates are possible, and a pre-tenant ClientId lookup only sees the ambient or default tenant's row. Consider (TenantId, Name) unique indexes, plus a decision on ClientId, through the Dapper migration mechanism, safe on existing 3.9 data.
""/null normalisation (#242)
Unique indexes that include TenantId depend on a consistent representation of the default tenant. Most databases treat NULLs as distinct in unique indexes, and "" and null are different values. Land the #242 normalisation first or together with this, or these indexes won't protect default-tenant rows.
Milestone: 3.10. Analysis is from #281's PR body.
Follow-up to #282 / #281 (role stores) and elsa-workflows/elsa-core#8615. Those fix roles only. On shared-store multi-tenant hosts, the identity user and application stores still have store-wide uniqueness problems.
Mongo
UserName_1unique (store-wide)adminuser, so the second tenant's admin seeding fails.ApplicationName_1unique (store-wide)ApplicationClientId_1unique (store-wide)ClientIdlookup can't apply a tenant filter. A compound(TenantId, ClientId)index would let two tenants reuse a client id, and resolution would become ambiguous or wrong. Keep it global unless the token/API-key pipeline is changed to resolve the tenant first.Proposed: compound unique indexes
(TenantId, Name)forUserandApplication.Name, using the same idempotent drop-old-and-create-new migration pattern as #281. Leave the decision onClientIdopen, with a store-global default.Dapper
Users/Applicationshave no unique index onNameorClientId(only theIdprimary key). Same-tenant duplicates are possible, and a pre-tenantClientIdlookup only sees the ambient or default tenant's row. Consider(TenantId, Name)unique indexes, plus a decision onClientId, through the Dapper migration mechanism, safe on existing 3.9 data.""/null normalisation (#242)
Unique indexes that include
TenantIddepend on a consistent representation of the default tenant. Most databases treat NULLs as distinct in unique indexes, and""andnullare different values. Land the #242 normalisation first or together with this, or these indexes won't protect default-tenant rows.Milestone: 3.10. Analysis is from #281's PR body.