User-Impersonierung bei Agent-User-Mapping #58

New issue

Closed

opened 2026-07-13 02:20:22 +02:00 by frank · 1 comment

frank commented

2026-07-13 02:20:22 +02:00

Owner

Ziel

Wenn Jobs über das Agent-User-Mapping (siehe #56) an einen Forgejo-Login gehen (z. B. @cursor / Assignee cursor), sollen die Agent-Aktionen als dieser User erscheinen — Kommentare, Reactions, Labels, PRs.

Zusätzlich sollen existierende gemappte Agent-User automatisch Schreibzugriff (write) auf alle watched Repositories bekommen.

Motivation

Heute authentifiziert sich forge agent watch als ein Admin-/Owner-Account. Mentions und Assignees können zwar auf Alias-User zeigen, aber Claim/Comments/PRs laufen weiter unter dem Admin-Login. Damit ist unklar, welcher Coding-Agent „gearbeitet“ hat.

Machbarkeit

Mechanismus	Ergebnis
OAuth-App	Nein — Token wirkt immer nur als autorisierender User
Admin-API-Sudo	Ja — Header `Sudo: <username>` bzw. `?sudo=`
Collaborator-API	Ja — `PUT /repos/{owner}/{repo}/collaborators/{username}` mit `permission: write`

Voraussetzung: authentifizierter Token ist Site-Admin (bzw. darf Collaborators verwalten); Ziel-User muss existieren. Accounts werden nicht automatisch angelegt.

Vorschlag

impersonate: true
agent_user: agent
# agent_mapping aus #56 liefert weitere Logins

Verhalten:

Bei impersonate: true: Admin-Check, Ziel-User per Sudo validieren
Alle Agent-API-Calls mit Sudo: <ziel-login>
Existierende gemappte Logins als Collaborators mit write auf watched Repos sicherstellen (fehlende User überspringen)
Git-Author/Committer für forge-eigene Commits aus dem Ziel-User setzen

Akzeptanzkriterien

Config/--impersonate + Fail-fast bei fehlendem Admin/User
API-Client unterstützt Sudo
Pipeline-Aktionen erscheinen als Ziel-User
Existierende Mapping-User erhalten write auf watched Repos
Tests + Wiki

Out of scope

OAuth-Impersonierung
Auto-Create von Forgejo-Usern
Collaborator-Rechte wieder entziehen
Vollständiges Mention-Routing (#56)

Related: #56

## Ziel Wenn Jobs über das Agent-User-Mapping (siehe #56) an einen Forgejo-Login gehen (z. B. `@cursor` / Assignee `cursor`), sollen die Agent-Aktionen **als dieser User** erscheinen — Kommentare, Reactions, Labels, PRs. Zusätzlich sollen **existierende** gemappte Agent-User automatisch **Schreibzugriff** (`write`) auf alle watched Repositories bekommen. ## Motivation Heute authentifiziert sich `forge agent watch` als ein Admin-/Owner-Account. Mentions und Assignees können zwar auf Alias-User zeigen, aber Claim/Comments/PRs laufen weiter unter dem Admin-Login. Damit ist unklar, welcher Coding-Agent „gearbeitet“ hat. ## Machbarkeit | Mechanismus | Ergebnis | | --- | --- | | OAuth-App | **Nein** — Token wirkt immer nur als autorisierender User | | Admin-API-Sudo | **Ja** — Header `Sudo: <username>` bzw. `?sudo=` | | Collaborator-API | **Ja** — `PUT /repos/{owner}/{repo}/collaborators/{username}` mit `permission: write` | Voraussetzung: authentifizierter Token ist Site-Admin (bzw. darf Collaborators verwalten); Ziel-User muss existieren. Accounts werden **nicht** automatisch angelegt. ## Vorschlag ```yaml impersonate: true agent_user: agent # agent_mapping aus #56 liefert weitere Logins ``` Verhalten: 1. Bei `impersonate: true`: Admin-Check, Ziel-User per Sudo validieren 2. Alle Agent-API-Calls mit `Sudo: <ziel-login>` 3. Existierende gemappte Logins als Collaborators mit `write` auf watched Repos sicherstellen (fehlende User überspringen) 4. Git-Author/Committer für forge-eigene Commits aus dem Ziel-User setzen ## Akzeptanzkriterien - [ ] Config/`--impersonate` + Fail-fast bei fehlendem Admin/User - [ ] API-Client unterstützt `Sudo` - [ ] Pipeline-Aktionen erscheinen als Ziel-User - [ ] Existierende Mapping-User erhalten `write` auf watched Repos - [ ] Tests + Wiki ## Out of scope - OAuth-Impersonierung - Auto-Create von Forgejo-Usern - Collaborator-Rechte wieder entziehen - Vollständiges Mention-Routing (#56) Related: #56

frank added the

agent:ready

label

2026-07-13 02:20:32 +02:00

frank commented

2026-07-13 02:23:15 +02:00

Author

Owner

Implementiert:

api.Client Sudo-Header + WithSudo
impersonate / --impersonate + Startup-Validierung (Admin + Ziel-User)
Agent-API-Calls als agent_user; Mentions sudo’en als Mapping-Login
Auto Collaborator-write für existierende gemappte Logins
Git-Author-Env für forge-Commits und Agent-Prozesse
Wiki: Agent-Watcher → Abschnitt User-Impersonierung

Siehe auch #56.

Implementiert: - `api.Client` Sudo-Header + `WithSudo` - `impersonate` / `--impersonate` + Startup-Validierung (Admin + Ziel-User) - Agent-API-Calls als `agent_user`; Mentions sudo’en als Mapping-Login - Auto Collaborator-`write` für existierende gemappte Logins - Git-Author-Env für forge-Commits und Agent-Prozesse - Wiki: Agent-Watcher → Abschnitt User-Impersonierung Siehe auch #56.

frank closed this issue

2026-07-13 02:29:48 +02:00