Bisher sah jede Anfrage alles. Jetzt traegt jede Abfrage eine
Besitzerbedingung, und zwar an erster Stelle in der where-Klausel statt als
nachtraeglicher Vergleich - so kann sie nicht versehentlich uebersprungen
werden.
- Lesen: findFirst statt findUnique, immer mit ownerId
- Schreiben und Loeschen: updateMany/deleteMany mit ownerId in der
where-Klausel. Fremde Datensaetze werden dadurch gar nicht erst getroffen,
und die betroffene Zeilenzahl sagt, ob es den Datensatz gab.
- Notizen haengen ueber project.ownerId am Besitzer
- Beim Verknuepfen eines Projekts wird geprueft, dass die Git-Verbindung dem
Aufrufer gehoert - sonst liesse sich eine fremde Verbindung und damit ein
fremder Token unterschieben
- Fremde IDs liefern 404 statt 403: die Antwort bestaetigt nicht einmal,
dass es den Datensatz gibt
- Ausgehende Endpunkte (Sync, Verbindungstest, Repo-Liste) zusaetzlich
ratenbegrenzt, Basis-URLs gegen den SSRF-Schutz geprueft
- Slug und Verbindungsname werden je Besitzer auf Eindeutigkeit geprueft
Nachgewiesen: ein zweites Konto erhaelt auf GET, PATCH, DELETE, Notiz
anlegen und Sync eines fremden Projekts durchgaengig 404, auf die
Admin-Endpunkte 403, und das Zielprojekt bleibt unveraendert.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
"Mein Konto": Profil, Passwort setzen oder wechseln, Passkeys anlegen,
umbenennen und entfernen, aktive Sitzungen einsehen und ueberall abmelden.
Der letzte Passkey laesst sich nicht entfernen, solange kein Passwort
gesetzt ist - sonst waere das Konto ausgesperrt.
Admin-Einstellungen: Betriebsart umschalten, Selbstregistrierung freigeben,
Konten anlegen, bearbeiten, deaktivieren und loeschen. Die Instanzwerte aus
der .env werden angezeigt, damit sichtbar ist, warum Passkeys gegebenenfalls
nicht verfuegbar sind.
Schutzregeln:
- Der Wechsel in den Einzelbetrieb wird abgelehnt, solange mehr als ein
Konto existiert.
- Der letzte aktive Administrator kann weder herabgestuft noch deaktiviert
oder geloescht werden.
- Das eigene Konto laesst sich nicht loeschen oder deaktivieren.
- Deaktivieren oder ein neues Passwort beenden sofort alle Sitzungen des
Kontos.
Administratoren verwalten Konten, keine Inhalte: fremde Projekte sehen auch
sie nicht.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- /setup fuehrt beim ersten Aufruf durch das Anlegen des Administratorkontos
und die Wahl der Betriebsart. Der Endpunkt funktioniert nur, solange es
keinen Benutzer gibt; danach kann sich niemand mehr nachtraeglich ein
Adminkonto erschleichen. Vorhandene Projekte ohne Besitzer werden dabei
uebernommen und im Formular vorher angekuendigt.
- /login mit Passwort oder Passkey. Der Passkey-Knopf entfaellt, wenn APP_URL
keinen sicheren Kontext ergibt - mit Hinweis, woran es liegt. Das Ziel nach
der Anmeldung wird auf relative Pfade begrenzt, sonst waere der
weiter-Parameter ein offener Redirect.
- /register nur im Mehrbenutzerbetrieb und nur, wenn ein Administrator die
Selbstregistrierung freigegeben hat.
- Kopfzeile mit Benutzermenue: eigenes Konto, Admin-Einstellungen, Abmelden.
Ohne Anmeldung bleibt sie auf das Logo reduziert.
- Layout liest Titel und Namen ueber generateMetadata, damit APP_NAME zur
Laufzeit greift statt beim Build eingefroren zu werden.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Alles, was die Oberflaeche kann, ist damit auch scriptbar:
GET POST /api/projects
GET PATCH DELETE /api/projects/:id
POST /api/projects/:id/sync
GET POST /api/projects/:id/notes
PATCH DELETE /api/notes/:id
GET POST /api/connections
PATCH DELETE /api/connections/:id
POST /api/connections/:id/check
GET /api/connections/:id/repos
GET /api/health
Details:
- Jede Eingabe laeuft durch Zod; Feldfehler kommen als Objekt zurueck, damit
Formulare sie direkt anzeigen koennen.
- Beim Anlegen werden Owner und Repo-Name aus der URL abgeleitet, falls nicht
explizit angegeben.
- Ein leeres Token-Feld beim Bearbeiten einer Verbindung laesst das
gespeicherte Token unveraendert; null entfernt es.
- Verbindungsantworten enthalten nie das Chiffrat, nur einen Hinweis
wie "ghp_...9f3a".
- /api/health prueft die Datenbank und dient dem Docker-Healthcheck.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
florian.wildeandClaude Opus 5