Berechtigungssystem

[axelrindle]

Ich hab das hier gefunden: https://github.com/stalniy/casl

Wo wir beim Thema "neue Sachen" ausprobieren waren.

[danielswiatek]

@Torge haben wir das nicht in abgewandelter form auch verwendet?

[Torge]

Wir benutzen casl in einem Projekt. Für ein anderes Projekt hatten wir uns mal aus verschiedenen Gründen dazu entschieden eine abgewandelte Form davon zu entwickeln. Zum einen brauchten wir ein dynamischeres Rollensystem und die Methoden von Services sollten sich unterschiedlich je nach Berechtigung verhalten. Das ist glaube ich aber nicht für das Projekt geeignet. Bei casl bin ich mir auch nicht sicher, ob wir das brauchen.

Ich denke für dieses Projekt können wir das ganze etwas einfacher gestalten. Die Endpunkte dürfen entweder von einer Rolle aufgerufen werden oder nicht. Das Ability System muss dann nicht die querys manipulieren können, wie man das mit casl kann. Ich finde es auch nicht so wichtig, dass das frontend schon zu build Zeit weiß was welche Rolle darf. Es langt denke ich, wenn der server das dem frontend nach dem Login mitteilt oder einfach im Frontend abhängig von der Rolle hardcoded Sachen aus- oder eingeblendet werden.
Wenn man die beiden Features nicht braucht, dann fallen schon zwei gute Gründe weg casl zu verwenden.

Ich würde vorschlagen bei den Endpunkte einfach zu definieren, welche Rolle diese aufrufen darf.
Das sehe dann eventuell so aus:

// api/services/user/index.ts
/** Die Liste aller User */
list: protectedProcedure(['ADMIN']).query(async () => {
  const users = await prisma.user.findMany({...})
  return users
}),
/** Die Liste der eigenen User*/
listOwn: protectedProcedure(['ADMIN', 'USER']).query(async () => {
  const users = await prisma.user.findMany({...}) // hier wird mit der userId des eingeloggten Benutzers gefiltert
  return users
}),

Die protectedProcedure checked dann ob der User diese Rolle hat. Im Endpunkt selber muss dann darauf geachtet werden, dass nur die Daten, wozu die Rollen dann berechtigt sein sollen, returned werden.

Was meint ihr?

[axelrindle]

Klingt der Einfachheit halber auch vernünftig. Für die Rollen würde sich eventuell auch ein Enum anbieten.

Wie genau könnte dann die rollenspezifische Unterscheidung der zurückgegebenen Daten aussehen? Macht das überhaupt Sinn, so eine Unterscheidung einzubauen oder reicht nicht doch eine einfache Abgrenzung der Endpunkte?

[Torge]

Für die Rolle gibt es an sich schon ein enum im Prisma Model. Das kann man dann auch im code verwenden um einzuschränken, was man protectedProcedure übergeben kann.
Durch verschieden Endpunkte je nach Berechtigung könnte man bestimmte Felder mit returnen oder halt nicht. Mir fällt aber auch noch kein konkretes Beispiel ein wann man das machen will. Ich fände das aber schick, wenn ein Endpunkt sich nicht groß unterschiedlich je nach Rolle verhält. Also z.B. user.list immer alle Nutzer zurück gibt und das nicht nach der Rolle eingeschränkt wird, sondern Nutzer den Endpunkt einfach nicht aufrufen dürfen. Deshalb auch list und listOwn
Was meinst du genau mit einer "einfache Abgrenzung der Endpunkte"?

[axelrindle]

Was meinst du genau mit einer "einfache Abgrenzung der Endpunkte"?

Genau das was du beschrieben hast :D Dass sich die Endpunkte nicht groß bzw. im Idealfall ja eigentlich gar nicht unterscheiden je nach Rolle.

Ein "Super Admin" darf z.B. Gliederungen anlegen usw. während ein Gliederungsadmin nur seine Gliederung verwalten darf.

Also "Super Admin" => POST /gliederung/create
Und "Gliederungsadmin" => POST /gliederung/{slug}/...