You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
AS default-client seeding is insert-only; seed-definition changes don't reach existing DBs #154
AuthorizationServerConfig.initializeDefaultClients(...) seeds the default ESPI clients with insert-if-absent semantics:
if (repository.findByClientId(client.getClientId()) == null) {
repository.save(client);
}
So once a client (e.g. third_party) exists in a database, changes to its seed definition never take effect on restart. Two such changes have already shipped that will NOT reach an already-seeded DB:
Any existing AS deployment (including the current dev/sandbox MySQL) will keep the stale third_party row and continue to reject the customer flow with the PKCE error until the client is re-created. Workarounds today:
fresh DB (re-seed from scratch), or
update the row via the admin API / SQL: set require_proof_key/client_settings appropriately on oauth2_registered_client where client_id='third_party'.
Options to consider
Upsert on startup — update existing default clients to match the seed definition. Risk: clobbers any admin-made changes to those clients on every restart.
Flyway data migration — one-off corrective migration to set require_proof_key=false (and names) on the known default client_ids.
Version/checksum the seed — only update when the seed definition version changes.
Option 2 is the lowest-risk way to fix existing deployments for the two shipped changes; option 1/3 is the longer-term answer for seed drift.
Surfaced during #148 (Phase 2.0 orchestration test).
Activity
fix(#154): reconcile default ESPI clients to code definition on start…