feat(backend): add system user auto-creation from application YAML

[fhennig]

For our staging environment, we want to initialize a system user with a known API key, that we can use right away from our collection seeding scripts.

This feature allows us to configure that system user in the applications.yaml:

dashboards:
  systemUser:
    githubId: "218605180"
    name: "Genspectrum Bot"
    email: null
    apiKey: "${SYSTEM_USER_API_KEY}"
  organisms:
    ...

And then set the env var (SYSTEM_USER_API_KEY).

In our deployment scripts we can then have a shared secret between the backend and the seeder container.

Summary

• Adds SystemUserConfig data class and optional systemUser field to DashboardsConfig
• Adds upsertApiKey(userId, rawKey) to ApiKeyModel — inserts on first run, rotates on key change, no-ops if hash is unchanged
• New SystemUserInitializer ApplicationRunner creates/updates the configured bot account and upserts its API key at startup

Test plan

• 4 integration tests in SystemUserInitializerTest cover: key creation + user existence, idempotency, key rotation (old key rejected / new key validates), lastUsedAt not reset on same-key re-run
• Add a systemUser block to a local YAML profile, start the backend, verify user appears at GET /users/{id} and key validates at POST /internal/api-keys/validate
• Restart with identical config → same user, same key, no errors
• Restart with changed apiKey → old key rejected, new key validates

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
dashboards	Ready	Preview, Comment	May 27, 2026 9:53am

[Copilot]

Pull request overview

Adds startup-time initialization of a configured “system user” (optionally with a pre-defined API key) from applications.yaml, intended for staging automation and seeding workflows.

Changes:

• Extend DashboardsConfig with optional systemUser configuration (SystemUserConfig).
• Add ApiKeyModel.upsertApiKey(userId, rawKey) to insert/rotate a provided API key.
• Introduce SystemUserInitializer ApplicationRunner plus integration tests covering creation/idempotency/rotation/lastUsedAt behavior.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
backend/src/main/kotlin/org/genspectrum/dashboardsbackend/config/DashboardsConfig.kt	Adds systemUser config block and SystemUserConfig data class for YAML binding.
backend/src/main/kotlin/org/genspectrum/dashboardsbackend/config/SystemUserInitializer.kt	New startup initializer that syncs the configured user and upserts its API key.
backend/src/main/kotlin/org/genspectrum/dashboardsbackend/model/apikey/ApiKeyModel.kt	Adds upsertApiKey to create/rotate a known key for a user.
backend/src/test/kotlin/org/genspectrum/dashboardsbackend/config/SystemUserInitializerTest.kt	Integration tests validating system user/key behavior and idempotency.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[fengelniederhammer]

🟡 Account identity collision via githubId

The systemUser.githubId in the YAML config uses a real GitHub user ID. Since syncUser is keyed on githubId, the system user and any OAuth user who logs in with the same GitHub ID are the same account. This means:

• If the configured githubId belongs to a real person, the system API key grants full access to that person's collections.
• Every backend restart, SystemUserInitializer overwrites the user's name and email back to the config values. Conversely, every OAuth login overwrites them to the GitHub profile values.
• If someone misconfigures githubId to another user's ID, the pre-seeded API key becomes an access key to that user's resources.

This isn't a bug per se (the intent is to use a dedicated bot account), but it should be documented explicitly: the configured githubId must be a dedicated bot/service account, never a real human user's ID.

---

Other findings are in the individual review comments above (toString key leak, empty key hash, test naming, missing test for null apiKey).

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.