The previous commit (37440171) added ApiScope rows for the
application scopes (admin, moderation, performer, client, blogs).
It was a partial fix: an ApiScope alone is not a valid scope from
DefaultResourceValidator's point of view. The validator only
recognises a scope if it can find an ApiResource that exposes it
(via ApiResourceScopes). Without that link, /connect/authorize
rejects the request with 'Scope X not found in store', even
though the scope row exists. This is what killed the PostIt login
in production.
This commit:
1. Extends Constants.ApiResourcesScopes with ResourceName +
ResourceDisplayName. Topology: one ApiResource per scope
('admin' resource exposes 'admin' scope, 'blogs' resource
exposes 'blogs' scope, etc.) — keeps each scope's audience
specific if/when we split products across separate audiences.
2. Ensures EnsureDefaultApplicationScopes also inserts the
matching ApiResource rows (deduped on Name) and ApiResourceScope
rows linking each resource to its scope. Idempotent: missing
rows are added, nothing is removed.
3. Removes the b.UseSeeding(...) call inside AddConfigurationStore.
EF Core's UseSeeding callback only fires when the database is
empty, so on a live ConfigurationDb (which already had Clients
and ClientScopes) it never ran — that is why the previous commit
had no visible effect on production. The seeder is now invoked
explicitly from MigrateDatabase via SeedConfigurationDatabase,
which resolves ConfigurationDbContext from the DI and runs
EnsureDefaultConfiguration on every startup, regardless of
whether the database was fresh.
Seeding failures are caught and logged (best-effort) so a
misconfigured seeder cannot prevent the host from booting.
Live data on yavsc.pschneider.fr is still missing the
ApiResource/ApiResourceScope rows; a one-shot SQL or a redeploy
with this commit is needed before PostIt can log in. Production
fix to follow.
