andrewmusselman opened a new issue, #33:
URL: https://github.com/apache/tooling-gofannon/issues/33
### Summary
The deployed-agent endpoint `/rest/<friendly_name>` and the run-code
endpoints all gate on `get_current_user`, which only knows how to read the
`gofannon_sid` cookie. CI runners can't get that cookie without the user-driven
login flow, so any headless / programmatic / scheduled use of Gofannon-deployed
agents is unworkable today.
### Details
**Problem:**
- GitHub Actions can't curl a deployed agent because they have no way to
obtain a session cookie.
- Scheduled jobs (cron, k8s CronJob) face the same issue.
- External integrations (other applications calling Gofannon agents as REST
APIs) can't authenticate.
- The current "headless" use case effectively requires putting a logged-in
browser tab in front of every workflow, which doesn't scale.
### Proposed solution
Three candidate directions, each a real feature requiring its own design
pass:
1. **Per-agent API keys** — smallest scope, most natural CI integration,
~200 LOC. Recommended first.
- User generates a key bound to a specific agent.
- Key authenticates requests to that agent only.
- Scoped, revocable, audit-loggable.
2. **Per-user service-account tokens** — more flexible, larger blast radius
if leaked.
- User generates a token that can call any agent they own.
- Like a long-lived session cookie but addressable by header.
3. **GitHub OIDC** — cleanest secret-handling, GHA-specific.
- GitHub Actions exchanges its OIDC token for a short-lived Gofannon
credential.
- No long-lived secrets on the GitHub side.
**Long-tail concerns** that all three share and need designing carefully:
- Rotation policy
- Scoping (per-agent / per-workspace / per-org)
- Audit logging
- Rate limiting per key
- Revocation flow
- UI for management
### Acceptance Criteria
*Phase 1 (per-agent API keys), separately defined:*
- [ ] Fixed: `AgentApiKey` model with hashed value, agent_id binding,
created_at, last_used_at
- [ ] Fixed: API endpoint to generate / revoke keys for an agent
- [ ] Fixed: Authentication middleware accepts `X-Gofannon-Key: gak_...`
header
- [ ] Fixed: UI for managing keys in the agent details view
- [ ] Test added: Valid key calls deployed agent successfully
- [ ] Test added: Revoked key returns 401
- [ ] Test added: Key bound to agent A cannot call agent B
- [ ] Documentation: GitHub Actions integration example
### References
- File: `webapp/packages/api/user-service/routes.py:get_current_user`
(existing auth check)
- File: `webapp/packages/api/user-service/routes.py` (deployed agent
endpoint)
- Tracker: FIXES.md item #11
### Priority
**Low / RFC** - Strategic feature requiring design pass. Depends on
ISSUE-003 (run registry) for async start + polling pattern that headless
callers need. Three candidate approaches; recommend filing per-agent API keys
(option 1) as the first concrete sub-issue once design lands.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
