Auth.js übernimmt nur den OAuth-Ablauf mit state und PKCE, Scope identify. Das Zugangstoken des Nutzers wird danach verworfen: die Rollen holt der Bot mit seinem eigenen Token. Die Sitzung steht in der Datenbank, im Cookie liegt nur userId und sessionId. Ohne die Zeile in Session ist das Cookie wertlos, und nur so lässt sich eine Sitzung zurückziehen. Wer sich anmelden darf, steckt in lib/auth/signInPolicy.ts statt im Callback: das ist die Regel, an der alles hängt, und sie gehört einzeln prüfbar. Kein Guild-Mitglied, kein Zugang. Keine Rolle mit grantsMembership, kein Zugang. Notfall-Admins umgehen die Rolle, aber nicht die Guild-Mitgliedschaft. RoleMapping trägt jetzt grantsMembership, category und isPresent. Der Worker spiegelt jede Rolle der Guild hierher, damit im Adminbereich nichts von Hand eingetragen werden muss. Gelöschte Rollen werden nicht entfernt, sondern auf isPresent = false gesetzt: beim Umzug auf den echten Server bleiben sie als Vorlage stehen. Der Worker gleicht über Gateway-Ereignisse und zusätzlich alle fünf Minuten voll ab. Verliert jemand seine AfiS-Rolle, beendet er dessen Sitzungen sofort und setzt isActive auf false — der Datensatz bleibt, damit Autorenangaben in alten Akten gültig bleiben. Das passiert im Worker und nicht in der Web-App, weil es dort erst beim nächsten Request des Betroffenen griffe. Zwei Widersprüche der Dokumente aufgelöst, festgehalten in docs/13-entscheidungen.md: der Ausschluss schlägt auch den Admin (das Codebeispiel in 03-auth-und-rechte.md übergeht ihn, die Reihenfolge eine Zeile darüber nicht), und versiegelte Akten fallen im Where-Fragment heraus statt in einer Prüfung danach. 45 Tests, davon die Negativfälle aus docs/03 gegen eine echte Datenbank: Stufe 2 sieht die Stufe-4-Akte nicht und findet sie auch nicht in der Trefferzahl, ein Ausgeschlossener mit Stufe 5 kommt nicht heran, ein Rollenentzug beendet die Sitzungen, und ein Ausfall der Discord-API sieht nicht aus wie eine verweigerte Mitgliedschaft.
64 lines
1.7 KiB
TypeScript
64 lines
1.7 KiB
TypeScript
/**
|
|
* Rechte-Enum aus docs/03-auth-und-rechte.md. RoleMapping.permissions ist in der
|
|
* Datenbank ein String[], diese Liste ist die verbindliche Menge gültiger Werte
|
|
* und die Grundlage der Kästchen im Adminbereich.
|
|
*/
|
|
export const PERMISSIONS = [
|
|
'case.read',
|
|
'case.create',
|
|
'case.edit',
|
|
'case.close',
|
|
'case.reopen',
|
|
'case.delete',
|
|
'case.edit_closed',
|
|
'entry.create',
|
|
'entry.correct',
|
|
'entry.edit_own',
|
|
'entry.edit_any',
|
|
'entry.retract',
|
|
'personnel.read',
|
|
'personnel.edit',
|
|
'template.manage',
|
|
'roles.manage',
|
|
'audit.read',
|
|
'export.approve',
|
|
'admin',
|
|
] as const
|
|
|
|
export type Permission = (typeof PERMISSIONS)[number]
|
|
|
|
/**
|
|
* Diese drei sind im Auslieferungszustand keiner Rolle zugeordnet. Der Leiter
|
|
* schaltet sie bewusst frei. Der Adminbereich weist beim Zuweisen darauf hin.
|
|
*/
|
|
export const OPT_IN_PERMISSIONS: readonly Permission[] = [
|
|
'entry.edit_own',
|
|
'entry.edit_any',
|
|
'entry.retract',
|
|
]
|
|
|
|
export function isPermission(value: string): value is Permission {
|
|
return (PERMISSIONS as readonly string[]).includes(value)
|
|
}
|
|
|
|
/** Aufgelöste Rechte eines Nutzers für genau einen Request. */
|
|
export type EffectivePermissions = {
|
|
userId: string
|
|
/** Höchste Stufe aller Rollen. */
|
|
clearanceLevel: number
|
|
/** Vereinigung aller Rollen. */
|
|
permissions: Set<Permission>
|
|
/** Aus BOOTSTRAP_ADMIN_IDS oder Recht 'admin'. */
|
|
isAdmin: boolean
|
|
/**
|
|
* Trägt der Nutzer eine Rolle, die zur Anmeldung berechtigt? Ergänzung
|
|
* gegenüber docs/03-auth-und-rechte.md: auf dem AfiS-Discord sind auch
|
|
* Gäste. Siehe docs/13-entscheidungen.md.
|
|
*/
|
|
hasMembership: boolean
|
|
}
|
|
|
|
export function can(p: EffectivePermissions, permission: Permission): boolean {
|
|
return p.isAdmin || p.permissions.has(permission)
|
|
}
|