Skip to content

Local manual-test kit: aligned AS/DC/TP local profiles, start/stop/smoke scripts, and docs/LOCAL_TESTING.md #254

Open

Description

@dfcoffin

Goal

One command starts the Authorization Server, Data Custodian and Third Party on the local profile (H2). The three apps are configured consistently with each other, and a runbook lists every URL, login, client credential and test recipe, so anyone can test the system by hand without reverse-engineering secrets.

Friction found while testing manually on 2026-11-14

  • AS has no UI login on local. admin_users starts empty, and the bootstrap needs a bcrypt hash in ESPI_BOOTSTRAP_ADMIN_PASSWORD_HASH, which I had to generate by hand.
  • The espi_admin and espi_registrar clients don't exist unless their secrets are passed at startup.
  • TP ↔ AS mismatches (detailed on TP bring-up: missing JAXB Atom marshaller, narrow component scan, and broader OAuth2-client wiring gaps #146):
    • TP client-secret: secret vs AS {noop}tp-secret;
    • TP redirect .../ThirdParty/login/oauth2/code/<id> is not registered on the AS, which lists only :9090/ThirdParty/oauth/callback and :8080/DataCustodian/oauth/callback;
    • TP requests openid,profile, which the opaque-only AS rejects (invalid_scope);
    • TP registration datacustodian doesn't exist, so the login button gives a 500 (Third Party: add a username/password login page matching the Data Custodian login design #249).
  • No AS client can mint ThirdParty_Admin_Access for the TP's own client: third_party_admin is a separate client.
  • No start/stop script. mvn spring-boot:run ×3 with per-app arguments, then killing them by port.

Proposal

  1. AS application-local.yml (local only, values marked DEV ONLY):
    • bootstrap admin admin/admin with a pre-computed bcrypt hash as the default for ESPI_BOOTSTRAP_ADMIN_* (a passkey is still enrolled at first login, by design);
    • fixed dev secrets for espi_admin and espi_registrar;
    • third_party redirect URIs for the TP at http://localhost:8082/ThirdParty/...;
    • drop openid/profile from the local third_party client.
  2. TP application-local.yml: registrations whose client id, secret, redirect URI and ESPI scope match the AS seed; provider URIs on localhost:9999; the third_party admin credentials for actuator introspection (feat: actuator health on all apps; other endpoints require an admin token #240). This is the configuration slice of TP bring-up: missing JAXB Atom marshaller, narrow component scan, and broader OAuth2-client wiring gaps #146, and it becomes the stored registration once Third Party: register itself via RFC 7591 dynamic client registration and manage its registration #252 lands.
  3. DC application-local.yml: already aligned for introspection (dc-secret, feat: actuator health on all apps; other endpoints require an admin token #240); add the sample data from DC local profile: seed a deterministic ESPI sample dataset (customer, usage, PII, ApplicationInformation) for manual testing #253.
  4. Scripts (scripts/local/):
    • start-all.sh and start-all.ps1: build once, start the three apps with the local profile, wait for each /actuator/health, print the URLs;
    • stop-all.*: stop the three apps by port;
    • smoke.*: obtain each client_credentials token, introspect one, call every DC feed and each app's admin actuator endpoint, and report PASS/FAIL. This is the non-interactive check before manual testing.
  5. docs/LOCAL_TESTING.md:

Acceptance

scripts/local/start-all then scripts/local/smoke passes on a clean checkout. Every login and client in LOCAL_TESTING.md works as written. No dev secret or seed applies outside the local profile.

Related

#146 (TP OAuth wiring: configuration part), #249 (TP login), #253 (DC sample data), #251 / #252 (registration), #241 (Flyway), #240 (actuator tokens)

🤖 Generated with Claude Code

Activity

  1. added a commit that references this issue on Nov 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestinfrastructureCI, build, deployment, or developer tooling

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions