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.
41 lines
1.2 KiB
TypeScript
41 lines
1.2 KiB
TypeScript
import { getEnv } from '@/lib/env'
|
|
|
|
const DISCORD_API = 'https://discord.com/api/v10'
|
|
|
|
export type GuildMember = {
|
|
userId: string
|
|
roleIds: string[]
|
|
nickname: string | null
|
|
}
|
|
|
|
/**
|
|
* Fragt die Mitgliedschaft **serverseitig mit dem Bot-Token** ab.
|
|
*
|
|
* Das Zugangstoken des Nutzers aus dem OAuth-Ablauf wird dafür bewusst nicht
|
|
* benutzt und nach dem Callback verworfen: OAuth klärt, wer jemand ist, der Bot
|
|
* klärt, was er darf. Siehe docs/03-auth-und-rechte.md.
|
|
*
|
|
* `null` bedeutet: kein Mitglied der Guild. Ein Fehler der Discord-API wird
|
|
* geworfen, damit ein Ausfall nicht wie eine abgelehnte Anmeldung aussieht.
|
|
*/
|
|
export async function fetchGuildMember(userId: string): Promise<GuildMember | null> {
|
|
const env = getEnv()
|
|
const response = await fetch(`${DISCORD_API}/guilds/${env.DISCORD_GUILD_ID}/members/${userId}`, {
|
|
headers: { authorization: `Bot ${env.DISCORD_BOT_TOKEN}` },
|
|
cache: 'no-store',
|
|
})
|
|
|
|
if (response.status === 404) return null
|
|
|
|
if (!response.ok) {
|
|
throw new Error(`Discord-API antwortete mit ${response.status}`)
|
|
}
|
|
|
|
const body = (await response.json()) as { roles?: string[]; nick?: string | null }
|
|
return {
|
|
userId,
|
|
roleIds: body.roles ?? [],
|
|
nickname: body.nick ?? null,
|
|
}
|
|
}
|