Eigene Identität in der API: prüfen + dokumentieren #147
Labels
No Label
area:auth
area:docs
area:export
area:ops
area:storage
area:supply-chain
auth
backend
blocked
collab
deployment
docs
effort:L
effort:M
effort:S
frontend
plugins
qa
vs-nfd
vs-nfd:blocker
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: stwaidele/dorfteich#147
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Ziel
Der Weg zur eigenen User-ID ist in der API-Doku klar auffindbar. Befund der Planung:
GET /api/v1/auth/me(intern) undGET /api/public/v1/me(PAT; liefert Nutzer + zugängliche Teiche,public-api.controller.ts:71) existieren bereits — der frühere Fehlbefund galt dem Pfad/users/me.Umsetzungsskizze
apps/api/src/public-api/openapi.ts) prüfen: ist/mebeschrieben, inkl. Hinweis „User-ID hier"? Sonst ergänzen.Akzeptanzkriterien
Befund bestaetigt und umgesetzt in PR #157 (
89ffbc0): GET /api/public/v1/me existierte bereits (liefert user.id/username/displayName, Scope, Teich-Beschraenkung) — der fruehere Fehlbefund galt nur dem Pfad /users/me. OpenAPI-Summary nennt jetzt ausdruecklich die User-ID, api-guide en+de ebenso; MCP war bereits paritaetisch. Kein neuer Endpoint noetig.