Maximilian Stubhan
b3a0af2b8f
Zweiter Schritt weg von Supabase. Sämtliche 49 Lesezugriffe und alle
Mutationen laufen jetzt über lib/db statt über die REST-Schicht: Kysely auf
einem pg-Pool, jede Abfrage in einer Transaktion, in der zuerst
app.user_id gesetzt wird. Die Anmeldung hängt noch an GoTrue — sie liefert
die Kennung, die in withUser() geht. Damit war der Umbau in zwei Hälften
teilbar und die Anwendung durchgehend lauffähig.
Was dabei ersatzlos verschwindet:
- fetchAllRows. Es gab die Funktion nur, weil PostgREST jede Antwort bei
1000 Zeilen still abschneidet und ein Bericht dann leise falsch war.
Am direkten Zugang ist eine Abfrage eine Abfrage.
- sanitizeIlikeTerm samt Test. Sie entschärfte Zeichen, die in der
Filtersyntax strukturelle Bedeutung hatten; jetzt wird der Suchbegriff
als Parameter gebunden und ein Komma ist ein Komma. Die Lücke ist nicht
abgesichert, sondern weg.
- lib/supabase/admin.ts. Der Dienstschlüssel, der RLS aushebelte, hatte
genau einen Aufrufer — den nächtlichen Lauf. Der benutzt jetzt dieselbe
Rolle ohne BYPASSRLS und ruft eine SECURITY-DEFINER-Funktion auf, die
selbst prüft, was sie tut. Es gibt keinen privilegierten Zugang mehr.
Nebenbei besser geworden, weil der direkte Zugang es erlaubt:
- Eine Seite ist eine Transaktion. Das Layout etwa liest Profil,
Planstellen, Standorte, Entwürfe und Notizen auf einem einheitlichen
Lesestand statt in fünf unabhängigen Anfragen.
- Der Bereichsfilter der Mitarbeiterliste ist ein EXISTS statt einer
eingebetteten Ressource mit !inner — eine Person mit mehreren
Zuordnungen über die Zeit erschien dort mehrfach.
- Seitenweise Listen sortieren zusätzlich nach id. Bei gleichem Nachnamen
oder gleichem Zeitstempel war die Reihenfolge vorher unbestimmt, und
dieselbe Zeile konnte auf zwei Seiten erscheinen oder auf keiner.
- Angehörige werden in der Datenbank gezählt statt alle Zeilen zu holen.
- Namen an Ereigniszeilen kommen aus einem Join statt aus einem
Nachschlag, der ausserhalb der Transaktion lag.
Der Statusfilter ist mitgezogen: dieselbe Regel wie deriveStatusAsOf,
Klausel für Klausel, jetzt als Kysely-Ausdruck. Der Integrationstest, der
beide über den gesamten Bestand vergleicht, läuft weiter — mit eigener
Verbindung, denn geprüft wird die Bedingung, nicht die Berechtigung.
Zwei Fehler auf dem Weg, beide vom Typprüfer gefangen: apply_due_pending_
changes() nimmt kein Argument, wurde von callFunction aber mit jsonb
aufgerufen — Postgres hätte keine passende Signatur gefunden. Und der
Sicherheitstest lädt jetzt Module mit `import "server-only"`, was ausserhalb
der Server-Übersetzung wirft.
Typecheck, Lint, Build und 180 Tests sind grün. Ungeprüft bleibt der Lauf
gegen eine echte Datenbank — dafür fehlt eine DATABASE_URL.
29 lines
1.4 KiB
TypeScript
29 lines
1.4 KiB
TypeScript
import { NextResponse, type NextRequest } from "next/server";
|
|
import { asSystem } from "@/lib/db";
|
|
import { callFunction } from "@/lib/db/rpc";
|
|
|
|
// Applies effective-dated changes (Versetzung/Beförderung/Karenz/Reorg/Daten
|
|
// ändern with a future "Wirksam ab" date) once their date has arrived — see
|
|
// apply_due_pending_changes() in supabase/migrations. Runs as a Vercel Cron
|
|
// job (see vercel.json), not on behalf of any HR user, so it authenticates
|
|
// via a shared secret rather than a Supabase session and uses the
|
|
// service-role client (the one legitimate server-only use case for it).
|
|
export async function GET(request: NextRequest) {
|
|
const authHeader = request.headers.get("authorization");
|
|
if (!process.env.CRON_SECRET || authHeader !== `Bearer ${process.env.CRON_SECRET}`) {
|
|
return NextResponse.json({ error: "Nicht autorisiert." }, { status: 401 });
|
|
}
|
|
|
|
// Kein privilegierter Zugang mehr: derselbe Datenbankbenutzer ohne
|
|
// BYPASSRLS wie überall. apply_due_pending_changes ist SECURITY DEFINER
|
|
// und prüft selbst, was sie tut — der Dienstschlüssel, der RLS aushebelte,
|
|
// ist damit entfallen.
|
|
try {
|
|
const applied = await asSystem((tx) => callFunction(tx, "apply_due_pending_changes"));
|
|
return NextResponse.json({ applied });
|
|
} catch (err) {
|
|
console.error("apply_due_pending_changes failed:", err);
|
|
return NextResponse.json({ error: "Interner Fehler." }, { status: 500 });
|
|
}
|
|
}
|