search

rowe42 / lhm_animad_admin_html5

0 stars 6 forks source link

Eigene Berechtigung für View-Zugriff #244

Closed rowe42 closed 6 years ago

rowe42 commented 6 years ago

Derzeit ist eine View in unserem Beispiel genau für eine Entität zuständig. Deshalb werden die Links im Menü deaktiviert, wenn die Berechtigung read<Entität>Allowed nicht vorhanden ist. Das können wir so nicht beibehalten, denn die Views können auch für mehrere (oder keine) Entitäten "zuständig" sein. Stattdessen sollte man eine zusätzliche Berechtigung einführen, die den Menü-Zugriff auf Views regelt.

xdoo commented 6 years ago

Da sollten wir noch ein bisschen überlegen. Ich gehe völlig konform, dass wir eine Art Berechtigung benötigen, um Views anzuzeigen. Art Berechtigung deshalb, weil es ja eigentlich keine ist. Zumindest nicht im Security Sinne. Wir sollten uns überlegen, wo diese "Frontend Berechtigungen" gespeichert werden sollen. So spontan hätte ich kein gutes Gefühl die mit den richtigen Berechtigungen zu verwalten. Aber so richtig greifen kann ich das noch nicht :)

rowe42 commented 6 years ago

Du hast recht, das wäre eine andere Art von Berechtigung als die, die wir jetzt haben. Das backend würde diese nicht brauchen / verarbeiten.

Ich könnte es auch erstmal so implementieren, dass wir eine View dann im Menü inaktiv setzen, wenn der Benutzer zu keiner der Entitäten zu den in der view vorkommenden Komponenten das READ Recht hat (dann hat er nämlich in der view nichts "verloren").

Was meinst du?

rowe42 commented 6 years ago

Ich nehme das zurück. Wenn ich so drüber nachdenke wäre das ziemlich kompliziert in polymer...

xdoo commented 6 years ago

Ich würde da eher eine grob granulare Lösung sehen. Aktuell gehen wir ja tatsächlich auf die Berechtigungen auf Methoden Ebene. Bei Menü würde ich eher auf die rollen gehen und die Konfiguration zu 100% im Frontend dem Entwickler überlassen. Der könnte dann entscheiden, welche Navigationsschaltflächen bei welcher Rolle angezeigt werden.

Das ist natürlich nicht so schön konfigurierbar wie unsere Backend Berechtigungen, aber es ist halt zu 100% eine Frontend Sache. Übergeben wir aktuell die Rollen ins Frontend?

rowe42 commented 6 years ago

Nein, die Rollen sind eine rein Keycloak interne Sache zur Gruppierung von Rechten. Weder Frontend noch backend haben darauf Zugriff und das finde ich auch gut, da man zur gleichen Rechte-Konstellation theoretisch über verschiedene Kombination von Rollen kommen kann.

Warum wäre es besser, im Frontend die Rollen zu verwenden anstatt expliziter Frontend-Permissions? Ich fände das genauso unsauber, wenn nicht sogar aus o.g. Gründen noch schlechter.

Dann lass uns vielleicht doch Frontend Berechtigungen einführen und hier halt vom Wording her deutlich machen dass es sich nicht um Rechte im eigentlichen Sinn handelt.

xdoo commented 6 years ago

Wenn wir nicht an die Rollen kommen, dann hat sich das eh erledigt.

Dann lass uns vielleicht doch Frontend Berechtigungen einführen und hier halt vom Wording her deutlich machen dass es sich nicht um Rechte im eigentlichen Sinn handelt.

Ja, lass uns das probieren.

rowe42 commented 6 years ago

Als Frontend-Berechtigungen im Format administration_GUI_KeepersView in Branch _#244 (user-service, admin-service (weil dort die KeyCloak-Config liegt) und html5) eingecheckt.

rowe42 commented 6 years ago

GUI-Permissions jetzt in master. @ejcsid hat noch ein Problem bemerkt, nämlich dass man die (versteckte) URL der Seite trotzdem aufrufen kann (dort aber auch weitere Rechte braucht, um etwas zu erreichen). Dafür wurde aber Issue #268 erstellt. Schließe dieses Issue.