|
|
|
|
|
|
|
Danke für den Input. Wer will, kann auch gerne mal den eigentlichen Post lesen.
Ich hab jetzt heute ein wenig dran rumgebastelt. Die Lösung bzw. der aktuelle Stand ist zwar nun (wirklich nur ein kleines bisschen) komplexer aber nicht komplizierter, trennt dafür aber alles, was getrennt gehört (so gut es geht).
| |
| Code: |
Policy
- Permission
- - Setting
- Permission
- - Setting
- - Setting
- Permission
- - Setting |
|
Die Policy beinhaltet eine PermissionCollection.
Jede Permission darin beinhaltet eine SettingCollection.
Jedes Setting ist ein Objekt vom Typ SingleChoiceSetting oder MultipleChoiceSetting* mit Properties ($options und $type, die zwar Default-Werte haben aber eben über die Policy gesteuert werden können) und 'ner Methode "render()", die ein Element lädt (in CakePHP heißen Partials Elements) und als String zurückgibt. Dabei entscheidet der Klassen-Typ über den Dateinamen. Diese render()-Methode versteht einen optionalen Parameter, um den Unterordner zu steuern, in denen nach den Dateien gesucht wird.
Aktuell sind's also zwei Dateien:
templates/element/(<subdir>/)?permission/setting/single_choice.php
templates/element/(<subdir>/)?permission/setting/multiple_choice.php
In den Dateien stehen $setting, $options und $type zur Verfügung. Anhand von $type entscheide ich, ob ich die $options als Radio-Buttons/Select (SingleChoice) oder Checkboxen/Select[multiple] (MultipleChoice) ausgebe.
Damit bekomme ich eigentlich erstmal alles so geregelt, wie ich das haben möchte.
* Ich hätte zwar die aktuelle Variante über eine einzige Klasse lösen und über ein Property $multiple = true|false steuern können, finde aber den Weg so gerade ein bisschen sauberer.
Und wenn ich ein Setting haben möchte, dass einen Colorpicker bereitstellt (warum auch immer man sowas brauchen wollen würde) oder eine Datums-Eingabe, kann ich das über entsprechende Klassen lösen.
----
Um mir das Leben ein wenig einfacher zu machen kennt auch die SettingCollection eine render()-Methode um alle darin geladenen Settings als String zurückzugeben:
| |
| Code: |
echo $permission->getSettings()->render('usergroups') |
|
Mein Arbeitskollege würde bei sowas anfangen zu kreischen, glaub ich. Gilt sowas als Codesmell?
----
Jetzt lande ich aber bei einem neuen Problem.
Bisher hat jede Permission selbst gewusst/entschieden, welche Optionen es gibt (ja/nein, ja/nein/egal, Liste mit Newskategorien) und wie diese als Formularelemente zur Verfügung gestellt werden. Dadurch war auch klar, was eine "1", die übertragen und so in die DB gespeichert wurde, zu bedeuten hat: War es ein "Ja"? Eine Kategorie-ID?
Das fällt jetzt aber komplett weg, wenn eine - von der Permission losgelöste - View bestimmen kann, welche Werte den Weg in die Datenbank finden. Ich muss also darauf vertrauen, dass in den Views selbst kein Quatsch passiert, da ansonsten Probleme auftreten können oder vor dem Speichern in die Datenbank die Werte verifizieren, in dem ich sie zurück an das entsprechende Setting gebe.
Ich kann das noch gar nicht richtig formulieren, welche weiteren Probleme mir hier in Gedanken schon begegnen. Ich bin aber auch nicht so wahnsinnig geschickt darin, alles erstmal theoretisch zu durchdenken, weshalb ich diese Posts auch für mich verfasst hab 
//Ich bin zur Zeit aber auch matschig im Kopf und hab den ganzen Spaß auch nie gelernt, weshalb mir manches (vieles?), was andere/ihr so raushaut, nicht direkt verstehe. Ich hab heute auch das erste Mal das Wort "Tupel" gehört. -_-
//Vllt. lass ich die Settings als zusätzliche, optionale Einstellungen laufen, die zusätzlich zu den eigentlichen Permissions gesetzt werden können. Dann bekommt die Permission ebenfalls eine render()-Methode, die nur die Rechtesteuerung betrifft.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Fabsn am 26.08.2021 2:28]
|
|
|
|
|
|
|
|
Also bitte.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Fabsn
Das fällt jetzt aber komplett weg, wenn eine - von der Permission losgelöste - View bestimmen kann, welche Werte den Weg in die Datenbank finden. Ich muss also darauf vertrauen, dass in den Views selbst kein Quatsch passiert, da ansonsten Probleme auftreten können oder vor dem Speichern in die Datenbank die Werte verifizieren, in dem ich sie zurück an das entsprechende Setting gebe.
| |
Ich glaube, hier liegt das Missverständnis. Die View bestimmt nicht, welche Werte in die DB dürfen, sie weiß nur wie Ressourceschema aussehen und bestimmt dann die Anzeige.
Zwangsweise musst du jeden Input aus der View prüfen. Es klingt etwas als wäre deine jetzige Lösung offen für injections oder zumindest für das Schreiben falscher Typen?
Du musst natürlich in den Ressourcen die Typen und Optionen definieren - deine UI components sollten je nach Typ eine Präsentation anbieten können - und natürlich musst du dann nach CRUD requests auch wieder Aktionsanfrage validieren.
Das render hat in deiner Permission Service oder an einer ACL nix zu suchen - das ist wirklich schon sehr smellig (separation of concern) und ultra tightes coupling vom fronted und backend, was dir bestimmt sehr schnell Kopfweh bereiten wird (und auch tut anscheinend  ).
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Tenz
Ich glaube, hier liegt das Missverständnis. Die View bestimmt nicht, welche Werte in die DB dürfen, sie weiß nur wie Ressourceschema aussehen und bestimmt dann die Anzeige. | |
Wenn die View entscheidet, welches Property von $newscategory[] im value-Attribut einer <option> steht, entscheidet sie erstmal auch, welche Daten per POST geschickt werden.
| | Zitat von Tenz
Zwangsweise musst du jeden Input aus der View prüfen. Es klingt etwas als wäre deine jetzige Lösung offen für injections oder zumindest für das Schreiben falscher Typen? | |
Dass diese dann nochmal überprüft werden müssen, ist klar. Aber wer übernimmt es?
Der Controller, der den POST-Request verarbeitet und damit ein Model anspricht? Dann weiß die Permission immer noch nicht, welche Daten übertragen wurden.
Die Permission selbst? Dann muss ich die POST-Daten im Controller vorher aber nochmal aufbereiten, an die Permission übergeben, dort validieren/sanitizen und dann zurückgeben. Ergibt natürlich den größten Sinn aber der Controller selbst kann das auch ignorieren. (Muss also entwicklerseitig immer bedacht werden, aber gut, so ist das ja bei vielen Dingen)
| | Zitat von Tenz
Das render hat in deiner Permission Service oder an einer ACL nix zu suchen - das ist wirklich schon sehr smellig (separation of concern) und ultra tightes coupling vom fronted und backend, was dir bestimmt sehr schnell Kopfweh bereiten wird (und auch tut anscheinend ).
| |
Wir haben leider grundlegend andere Definitionen von Backend und Frontend, weshalb da weiter drüber zu sprechen etwas schwieriger werden dürfte. Das Backend ist für mich immer die Admin-Oberfläche eines CMS, das Frontend die daraus resultierende Webseite für reguläre Besucher/Kunden/Onlyfans-Wechsler.
Aber wohin gehört das Rendern von Elements denn, wenn ich auf keinen Fall an jeder Stelle, die eine Permission bzw. ein Setting rendern können soll, eine Logik zur Übergabe von notwendigen Parametern und das Suchen von (Default-)Views definieren möchte?
Also ich verstehe den Einwand "separation of concern" nicht.
//CakePHP kennt Helpers. Ein PermissionHelper bzw. sogar ein zusätzlich SettingHelper wäre dann wohl der klügere Weg?!
//Ey, auch wenn das evtl. rude klingt aber ich bin so dankbar für jede Antwort. Mir fehlt sonst jegliche Anlaufstelle für sowas.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von Fabsn am 26.08.2021 11:38]
|
|
|
|
|
|
|
|
|
|
Was immer Du machst, zertifizier doch mal Deine Webseite.
|
|
|
|
|
|
|
|
|
|
|
|
Das ist keine Website, da liegt einfach seit Jahren überhaupt nichts. Hättest ja aber selbst mal https:// vorne dran hängen können!!!11
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Fabsn am 26.08.2021 11:45]
|
|
|
|
|
|
|
|
|
|
Haha ja, auch eben aufgefallen. Dein Root ist zertifiziert, aber halt leer.
|
|
|
|
|
|
|
|
|
|
|
Was Dir fehlt sind Profile und Rollen.
Den Profilen sind Rollen zugeordnet.
Den Benutzern sind Profile zugeordnet.
z.B.:
Rollen:
"darf Buch lesen", "darf Buch anlegen", "darf Buch updaten"
Profile:
"darf Buch alles" wo alle 3 Rollen hinterlegt sind.
"darf Buch nur lesen" wo nur "darf Buch lesen" hinterlegt ist.
Der View wird dann je nach erlaubter Rolle dargestellt.
Du verstehst, was ich meine?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von _Gogo_
Du verstehst, was ich meine? | |
Nein, denn das fehlt ja nicht, das existiert ja. Was du Rollen nennst, sind bei mir Permissions. "Profile" sind die lose Verbindung von Policies mit frei wählbaren Permission-Checks (siehe langer Post).
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Fabsn
Wenn die View entscheidet, welches Property von $newscategory[] im value-Attribut einer <option> steht, entscheidet sie erstmal auch, welche Daten per POST geschickt werden. | |
Ein rendern aus deiner PermissionKlasse heraus verhindert leider gar nichts; denn der Client entscheidet ohnehin immer, was in der POST steht, die View bietet hier nur ein öffentliches Interface.
Wenn deine App also so aufgebaut ist, kannst du dir ohnehin Muppes via JS, oder halt sogar einfach DOM-Edit via Devtools, in die DB schicken, das ist maximal gefährlich.
Du verarbeitest den POST natürlich irgendwo in deinem Service, im Model oder im Controller, Hauptsache im Backend.
Frontend = Client & User Interface
Backend = Serverseitige Logik - ob Middleware, DB, Controller, oder was auch immer. Bei MVCs passiert das am ehesten im zwischen M und C im Dialog.
Das User Interface deines Adminbereiches ist Frontend, das ist die View-Domain. Deine Rechte-Logik und die Controller und Endpoints deiner Ressourcen, das ist Backend.
Grundsätzlich ist dein Backend immer die Autorität.
Beispiel:
Du willst ein Kennzeichen anmelden - du hast prinzipiell die Möglichkeit hier alle Formulare falsch auszufüllen oder da Mumpitz reinzuschreiben. Oder dir irgendwelche prutschigen Kennzeichenplaketten zu kaufen die nicht StVO-Konform sind.
Das Formular ist ja nur ein offizielles Dokument, welches es dir und der Autorität lediglich erleichtern soll, miteinander zu kommunizieren. Für die Autorität ist es wichtig, dass die Daten möglichst konsistent zu verarbeiten sind. Für den Antragsteller ist es wichtig, dass das Formular benutzerfreundlich ist.
Eine Admin-Oberfläche ist nichts anderes als ein Formular, welches dir _hilft_ die richtigen Anfragen auszufüllen. Jemand wird aber _immer_ (pralle) Penen auf dein Formular zeichnen können - das verhindert du auch nicht, in dem der Sachbearbeiter persönlich dir jedes Formular ausdrucken muss. Das mit dem Ausdrucken durch den Sachbearbeiter (inkl. Layouting vom Dokument) ist aber quasi das Äquivalent zu deiner render() Methode an deinem Policy/Permission Service.
Wie das Formular aussieht ist also nicht Aufgabe von dem, der das Formular bearbeitet; weil das erstens nicht sein Job ist, sondern ein Job für die Abteilung die sich um das Design der Formulare kümmert (frontend).
Um die Verteilung / den Ausdruck der Formulare kümmert sich ein Backend-controller - also ggf. die Leute an der Information, die dir sagen an welchen Schalter du sollst und welches Formular du da schon mal abgeben darfst.
Ein POST ist also erst mal ein willkürlicher Antrag, der hoffentlich mit dem offiziellen Formular und ohne Hirnschiss ausgefüllt würde.
Wenn jetzt die Formulare aktualisiert werden müssen oder Einzelentscheidungen darüber getroffen werden müssen welche Darstellung für ein Feld sinn macht, dann wird diese Frage nicht den Sachbearbeitern gestellt - für die Ändert sich nichts, auch wenn die Formulare alle auf ein mal Blau sind und der Text größer - oder welches Layout mehr Sinn macht.
Ein gutes Frontend ermöglicht nur einen statistisch stabilen Eingang an möglichst bereits validen Daten.
Aber,
die gleiche Autorität, die deiner View sagt:
"Das hier soll am besten auf dem Formular stehen, hier hat der Benutzer Zugriff drauf, das ist was eher sehen kann und was er damit macht, bitte schickt ihm das richtige Formular dafür damit uns allen Arbeit erspart bleibt", prüft dann auch wieder den POST/Antrag.
Das würde ich in deinem Fall also als Job deiner UserPolicies-Klasse ansehen (oder welche auch immer); nachdem dein Controller den POST entgegen genommen hat, ggf. rudimentär auf Vandalismus geprüft hat und dann deinem Service die richtigen Fragen stellt.
(Je nachdem wie Umfangreich dein Rechte-Management hier sein muss bist du entweder direkt bei ACLs, wie Rats schreibt, oder du startest flacher - aber der Part ist ja abgedeckt).
Hinweg:
Der Controller bekommt die Anfrage auf /edit-news und bittet den Policy-Service darum, für die gefragte Ressource das heraus zu filtern, was der Benutzer nicht sehen darf; und gleichzeitig wären noch ein paar Notizen cool mit Info darüber was der Benutzer noch so machen darf damit. Der Controller reicht das weiter an die View. Die View kann dann die Entscheidung treffen, wie das Formular aussieht.
Die View interessiert also nur: Die Daten darf ich anzeigen und hier in der Notiz steht ob es Sinn macht dem Benutzer auch zu sagen, dass er die Daten editieren kann. Außerdem beachtet die View Notizen über den Typ der Daten, also z.B. ob es ein freier Wert ist oder es folgende Optionen gibt, die gewählt werden müssen und ob das einzelne oder mehrere sein können.
Die View kümmert sich dann darum, wie man den Shizzle am besten darstellt und hat für jeden Typ ggf. schon eine Standardansicht in Petto; z. B. ein schönes Dropdown für diese Einfachauswahl an Optionen.
Dann kann es sein, dass es Benutzerfreundlicher ist diese Optionen als Radio-Button darzustellen (weil es typischerweise nur zwei kurze ja/nein Einträge sind), also Entscheidet sich die View dazu hier kein Dropdown für dieses Feld anzuzeigen.
Kann ja auch sein, dass Leute immer wieder kackige Fehler machen bei diesem einen Eintrag; oder sich ggü. den Formularen aus dem letzten Jahrhundert was geändert hat. Also müssen wir an der Stelle eine dicke, fette, lila Randnotiz und einen Rahmen um das Formular pappen, damit der passiv-agressive Randnotizshizzle auch beachtet wird.
Sowas kann sich also unabhängig von der eigentlichen Struktur der Daten ändern. Weshalb du auch willst, dass diese Entscheidungen alle auf View-Ebene zentral gelöst werden. Du willst nicht darauf warten, dass alle Sacharbeiter darüber informiert werden ihre Layouts anzupassen - weil's nicht deren Job. Das ist "Separation of Concerns" und quasi Mittelpunkt einer MVC-Architektur für diese Ebene.
Das war der Hinweg. Der Rückweg is dann so:
View -> POST -> Controller so "Ah ein POST", hier Service, check bitte den POST, ich bin evtl. auch so nett und sanitize dir die Daten vorher, dann stehen schon mal keinen Penen drauf aber sach mir ob ich der View sagen soll ob seine Anfrage klar ging (Grüne Karte) oder nich (Rote Karte) -> Service checkt die Daten, meldet ggfs. ok/nicht okay zurück und updated dein Model.
/e: Lies dich auf jeden Fall noch mal in die MVC-Architektur ein.
Und deine Definition von Fronend/Backend müsstest du wirklich 1x updaten - mir ist auch klar, dass "Backend" oft als Synonym für die Admin-UI genommen wird, das ist aber dann nur ein Begriff in der Domain des Endbenutzers und nicht aus architektorischer Schicht - ich glaube, dass ist das was dich evtl. am meisten davon abhält, den "richtigen" Platz für die Verarbeitung der Daten in deinem Setup zu finden 
/e: Update2:
| | Zitat von Fabsn
Ergibt natürlich den größten Sinn aber der Controller selbst kann das auch ignorieren. (Muss also entwicklerseitig immer bedacht werden, aber gut, so ist das ja bei vielen Dingen) | |
Als Entwickler wirst du immer Dinge ignorieren können, das kannst du nur durch klare Dokumentation, ggf. Typisierung und Automatischen Tests und Code Reviews unterbinden. Und natürlich in dem du deine Schnittstellen so verallgemeinerst, dass die auch einfach zu Benutzen sind - zum Beispiel in dem du für deine Controller ein Bestimmtes ControllerInterface definierst, dass der Entwickler auch implementieren muss - ansonsten bimmelt die IDE.
Das heißt nicht, dass der Controller nicht trotzdem derjenige ist, der den POST bearbeitet und ggf. einen Service um Hilfe fragt und nicht einfach davon ausgeht, dass die View schon das richtige durch schickt
| | Zitat von Fabsn
//Ey, auch wenn das evtl. rude klingt aber ich bin so dankbar für jede Antwort. Mir fehlt sonst jegliche Anlaufstelle für sowas. | |
Ich kling sicher auch wie ein richtiger Wichser, ist aber null so gemeint. X-Tender bin ich mit der Art auch auf den Sack gegangen
|
|
[Dieser Beitrag wurde 13 mal editiert; zum letzten Mal von Tenz am 26.08.2021 14:38]
|
|
|
|
|
|
|
|
|
| | Zitat von Fabsn
| | Zitat von _Gogo_
Du verstehst, was ich meine? | |
Nein, denn das fehlt ja nicht, das existiert ja. Was du Rollen nennst, sind bei mir Permissions. "Profile" sind die lose Verbindung von Policies mit frei wählbaren Permission-Checks (siehe langer Post).
| |
Schau dir trotzdem mal existierende Berechtigungsmodelle wie RBAC (ACLs mit Gruppen ist ca. das gleiche) an, für mich klingt das was du machst so, als ob du für jede Art von Ressource ein ad-hoc Berechtigungsmodell schreibst und du deswegen an der Stelle stehst, wo du für jedes dieser Modelle ein eigenes UI für Änderungen brauchst, und dann kommt man auf die Lösung irgendwie das UI abtrennen oder abstrahieren zu wollen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Tenz
Die View entscheidet immer, was in der POST steht, ein rendern aus deiner Permissionklasse heraus verhindert da gar nichts. Wenn deine App so aufgebaut ist, kannst du dir ohnehin Muppes via JS, oder halt sogar einfach DOM-Edit via Devtools, in die DB schicken, das ist maximal gefährlich.
| |
Ich verstehe das Problem nicht. ORM bzw. DB-Adapter übernehmen die Absicherung vor SQL-Injections. Model/Table bzw. Model/Entity übernehmen die Zuordnung der Daten in zu den entsprechenden Spalten sowie Typ-Prüfung und/oder Konvertierung.
XSS-Attacken sind nicht möglich, da die Werte, die aus der DB kommen, nirgendwo ausgegeben werden. Es kann also im schlimmsten Fall nur dazu führen, dass jemand Daten in die Datenbank schreibt, mit denen eine Permission dann beim Überprüfen einfach nichts anfangen kann und dadurch dann der Default-Zustand ("Kein Zugriff") greift?! Zum Beispiel weil als Wert "Klar darf ich das" oder "<script>alert('lol')</script>" statt "1" in der Spalte "access" steht.
Und jede Person, die Zugriff auf die Userverwaltung hat, kann sich logischerweise schon über das normale Formular selbst alle Rechte geben - da braucht es keinen Umweg.
Das Problem ist eigentlich das:
Wenn die Permission Werte validiert, dann bedeutet das noch nicht, dass dieser validierte Wert auch genau so in der DB landet, da eben Table resp. Entity dafür zuständig sind.
Ich muss also dafür sorgen, dass die Werte, die in der DB stehen, für die Überprüfung wieder in solche umgewandelt werden, die die Permission versteht. Ansonsten müsste die Permission schon wissen, in welche DB-Tabelle ihr Wert geschrieben wird aber dann hat man wieder 'ne Verbindung, die so ja nicht existieren sollte.
| | Zitat von Tenz
Und deine Definition von Fronend/Backend müsstest du wirklich 1x updaten - mir ist auch klar, dass "Backend" oft als Synonym für die Admin-UI genommen wird, das ist aber dann nur ein Begriff in der Domain des Endbenutzers und nicht aus architektorischer Schicht - ich glaube, dass ist das was dich evtl. am meisten davon abhält, den "richtigen" Platz für die Verarbeitung der Daten in deinem Setup zu finden | |
Ja ich verstehe das schon aber das werd ich nie geändert bekommen. 90% meiner Kolleg:innen sind Nicht-Programmier und sowohl für die, als auch für (fast) alle Kunden stehen die Begriffe Frontend und Backend eben genau dafür: Webseite & Adminoberfläche. Ob jetzt andere Begrifflichkeiten das Finden der "richtigen" Stellen erleichtert bzw. überhaupt erst ermöglicht? Ich weiß nicht, aber ich probier's mal. Auch wenn ich in der Agentur schon immer gegen die "Das haben wir schon immer so gemacht"-Wand renne.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Schau dir trotzdem mal existierende Berechtigungsmodelle wie RBAC (ACLs mit Gruppen ist ca. das gleiche) an
| |
Und dann? 
Das löst ja meine Probleme nicht und ich weiß auch nicht, was ich dadurch lernen soll.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Fabsn
Das Problem ist eigentlich das:
Wenn die Permission Werte validiert, dann bedeutet das noch nicht, dass dieser validierte Wert auch genau so in der DB landet, da eben Table resp. Entity dafür zuständig sind.
Ich muss also dafür sorgen, dass die Werte, die in der DB stehen, für die Überprüfung wieder in solche umgewandelt werden, die die Permission versteht. Ansonsten müsste die Permission schon wissen, in welche DB-Tabelle ihr Wert geschrieben wird aber dann hat man wieder 'ne Verbindung, die so ja nicht existieren sollte.
| |
Zum teil richtig, ein Part liest sich aber wie eine derbe red flag.
Erst mal zum richtigen Part: Deine Policy ist ja auch nur der eine Teil, der entscheidet ob die Aktion überhaupt im Model ankommt. Für die eigentliche Transformation von Daten in das richtige Schema ist das Model verantwortlich.
Deshalb hast du ja einerseits deine Ressourcen, also dein Model Repository, und andererseits deine Policies. Beide bringt der Controller zusammen, über den die Anfrage läuft. Die View ist da komplett außen vor.
Du kannst natürlich auch die Policy-Checks direkt im Model abbilden und nicht im Controller - das ist immer eine Entscheidung die man nur mit Blick aufs ganze treffen kann, letztendlich sollte die Idee aber klar sein.
Hier die red flag - nur für den Fall, dass du dich nicht verschrieben hast:
| | Zitat von Fabsn
"Ich muss also dafür sorgen, dass die Werte, die in der DB stehen, für die Überprüfung wieder in solche umgewandelt werden, die die Permission versteht. " | |
Wenn du Werte in die DB schreibst, bevor die für eine Prüfung umgewandelt werden welche darüber bestimmen muss ob die Überhaupt in der DB landen können, läuft auf alle Fälle was schief. Wahrscheinlich interpretiere ich das falsch, aber sicher ist sicher
/Update:
Du willst drei folgende Checks, wobei jeder Check die Möglichkeit hat in das benötigte Error-Handling zu springen. Alle Checks passieren nach dem POST.
a) Ein check, der erst mal überprüft ob die CRUD-Aktion im Request ausgeführt werden darf von dem Benutzer, das sagt dir dein PolicyService.
b) Dann ein generischer Check, der einen Sanitizer laufen lässt, hier gehts um Encodings, Injections, was weiß ich.
c) Dein Model, das checkt ob die gesäuberten Daten, die so ankommen weil der Benutzer das prinzipiell darf, überhaupt ins Schema passen bzw. für das Schema noch mal transformiert werden.
Schau dir dazu noch mal an, welche Aufgaben das Model im MVC alle hat - die gehen weit über das Ausführen von DB queries hinaus.
| | | Und jede Person, die Zugriff auf die Userverwaltung hat, kann sich logischerweise schon über das normale Formular selbst alle Rechte geben - da braucht es keinen Umweg. | |
Ich glaube wir gehen hier alle davon aus, dass es um ein Rechtemanagement (deshalb Rats info zu ACL) geht, welches individuelle Rechte und Benutzergruppen steuern muss. Wenn das alles nur Superuser sind, brauchst du doch auch kein Policy-Management?
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von Tenz am 26.08.2021 14:57]
|
|
|
|
|
|
|
|
|
Ne, falsch verstanden. Model/EntityUsergroupsPermission wandelt alles, was in die Spalte "access" muss, in einen Integer um. Aktuell übermittelt die Permission auch genau das.
Theoretisch könnte die Permission aber die Strings "ja", "nein" oder "vielleicht" zurückgeben, was dann ja so nicht in der DB landen kann.
Es muss also vor dem Check wieder von einem Integer zu einem ja/nein/vielleicht gewandelt werden. Aber halt nur für den Fall, dass Wert (bzw. Datentyp) der Permission und der Spalte in der DB-Tabelle nicht matchen.
| | Zitat von Tenz
Ich glaube wir gehen hier alle davon aus, dass es um ein Rechtemanagement (deshalb Rats info zu ACL) geht, welches individuelle Rechte und Benutzergruppen steuern muss. Wenn das alles nur Superuser sind, brauchst du doch auch kein Policy-Management?
| |
??? Wah? Wer sagt denn, dass alle "Superuser" sind? Jemand, der keine User bzw. Usergroups bearbeiten darf, kommt gar nicht erst an eine Stelle, an der er Permissions setzen/verändern kann und damit auch nicht an eine Stelle, wo irgendwelche schlimmen Daten den Weg in die DB finden könnten.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von Fabsn am 26.08.2021 15:03]
|
|
|
|
|
|
|
|
|
Nein, halt, stop.
Dein Permission-Service is doch nur der Türsteher. Wie der Antwortet ist der DB scheiß egal, du gibst ja nicht die Antwort von dem Kerl an die DB weiter sondern lääst nur den Fratzke mit seinem Antrag da überhaupt durch die Tür in den nächsten Raum. Das ist reines Authorisierungs-Layer.
Permission != Validierung vom Schema - du versuchst beides quasi gleichzeitig zu machen und verkomplizierst dadurch deine Architektur. Deshalb werfen sich ja erst die Fragen auf die du stellst
Permissions beantworten fragen über:
- Was aus dem Model darf der User sehen,
- Was aus der View darf der User sehen (macht auf oberster Linie deine Middlewear was zumindest das reine Aufrufen angeht)
- Darf der User die Update/Delete/Insert-Interfaces vom Model nutzten oder begrenzt sich das nur auf bestimmte Felder
Dein Model selbst beantwortet fragen über:
- Sieht der Wert richtig aus? Bzw. ist das ein Wert, den ich Umwandeln kann/muss?
- Danke für deine Anfrage, hier sind die Daten, ich hab das gelöscht, blahblah
Das Model ist erst mal offen für jeden Scheiß, du musst dich vorher drum kümmern ob derjenige überhaupt mit der Anfrage zum Model darf.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Tenz am 26.08.2021 15:07]
|
|
|
|
|
|
|
|
|
Hä?
Wir sind hier irgendwo falsch abgebogen bzw. siehst du das Model hier als etwas, das es nicht ist.
Ich versuch mal, das ganze Konstrukt zu beschreiben, ohne dass es zu kompliziert wird.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Fabsn am 26.08.2021 15:09]
|
|
|
|
|
|
|
|
|
Wir sind auf alle Fälle vom Ursprünglichen abgedriftet - mein längerer Post zu den Views ist glaube ich der mainbranch
Aus deinem Dokument:
| | Zitat von Fabsn
[b]
Der eigentliche Grund für den ganzen Text, auch wenn sich durch das Aufschreiben deutlich mehr Überlegungen und Probleme - aber auch Lösungen - ergeben haben:
In der Verwaltung (Anlegen und Bearbeiten) von Usergroups suche ich alle Policies und gebe für jede Ressource ein Formularfeld aus. Für die SimplePermission gibt es drei Radio-Inputs, je eines für ja/nein/mir egal.
Diese Formularfelder generiere ich über $permission->getFormElements() und gebe sie in den Views für add/edit des UsergroupsController aus. Die Permission bestimmt also selbst, welche Felder zur Steuerung bereitgestellt werden. Das ergibt für mich den größten Sinn.
Allerdings heißt das auch, dass die Stelle, an der diese Formularfelder letztlich ausgegeben werden, keine Möglichkeit hat, diese Felder zu beeinflussen. Ich kann also in einer View aus der ja/nein/egal-Radio-Auswahl kein <select> bauen oder die Reihenfolge der Optionen verändern.
Ist das sinnvoll, das so zu machen oder sollte eine Permission die Formularfelder gar nicht selbst generieren sondern nur die möglichen Optionen zurückgeben und die verarbeitende Stelle entscheidet dann, wie sie ausgegeben wird? Das hab ich auch überlegt, aber wenn es über eine einfache Auswahl von Optionen hinausgeht, kriege ich damit schon wieder Probleme:
Angenommen eine Permission verfügt neben der Auswahl für ja/nein auch noch über eine Eingrenzung, zum Beispiel weil eine Gruppe nur News aus der Kategorie X sehen/bearbeiten können soll. Dann brauch ich eben noch ein Dropdown-Auswahlfeld mit allen Newskategorien.
Ich müsste also der add/edit-View der Usergroups die Info zukommen lassen: "Hier sind zwei Optionen, bitte als Radio darstellen wenn möglich. Zusätzlich noch eine Liste an Entities. Diese bitte als <select> generieren. Attribut 'multiple' is aber Pflicht, ne?!".
Zwar trenne ich da in gewisser Hinsicht die Abhängigkeiten, brauche aber eine neue Lösung für den Informationsaustausch und damit dann doch wieder eine Abhängigkeit, wenn auch über eine dritte Einheit, die noch dazu proprietär ist. Was tun?
| |
Lösung: ->getFormElements gibt nicht Formelements aus sondern einen OptionType, d.h. eine Datenstruktur. (Führt wieder auf meinen Ursprungspost von letzte Seite btw.).
OptionType<SelectFromPreset>:
[
OptionValue:[],
key: String,
id: PositiveInteger,
displayDescription: String,
displayName: String,
maxOptions: PositiveInteger
]
OptionValue<Type>:
[
displayValue<String>,
value<Type>
]
Der konkrete OptionType "SelectFromPreset" hat n mögliche Optionen/Werte, einen DisplayName (fürs Label z.b.) und eine DisplayDescription (vllt. für den Help-Tooltip).
Außerdem einen Key damit du immer die Möglichkeit hast über den Inhalt der Daten auch in der View Vermutungen anzustellen*.
Deine View kann dann selbst Entscheiden, ob sie für einen OptionType "SelectFromPreset" einen Dropdown oder einen Radiobutton nutzt, dafür hat sie die Anzahl der Entries und maxOptions um zu entscheiden obs ein Multiselect ist.
*
Key kann z.B. sein: "policyOption". Dann kannst du in der View sagen "Geil is policyOption, hier hab ich ein derb spezifisches Layout für den Fall". Oder es ermöglicht dir eine NameConvention, so dass du ein Templatepartial nur als policyOptionFormElement.irgendwas in /admin/template/components/formElements/ ablegen musst und dann wird das per Default genutzt. Wenn der nicht vorhanden ist, dann halt die /admin/template/components/formElements/SelectFromPresetFormElement.irgendwas dafür geladen.
---
D. h. erst mal eine Bandbreite an OptionTypes zu definieren macht Sinn:
Type SelectFromPreset für Dropdowns aus div. Optionen
Type InputField für, ja Inputfields halt
Type SwitchState für so ja/nein/vllt. Geschichten, in dem Fall definierst du ein Enumerable für die drei States mit dem der Type arbeiten darf.
Die Types sind quasi dein Schema bzw. helfen dir das Schema in deinem Model zu validieren. Dein Model sollte also für jeden Type wissen, wie dieser in Hinblick auf den Access-Flag umzusetzen ist. (Offensichtlicher Nachtrag: natürlich ist es Sinnvoll das ggf. zu normalisieren)
Das ermöglicht dir anhand des Types
- a) in der View Fallentscheidungen zu treffen wie die Option angezeigt wird. Die Werte für die Optionen kommen fest aus dem Type bzw. dessen Implementation, die ziehst du dir ja nicht aus der Nase in der View.
- b) den POST danach im Model auf der selben Basis wieder zu validieren
|
|
[Dieser Beitrag wurde 9 mal editiert; zum letzten Mal von Tenz am 26.08.2021 15:47]
|
|
|
|
|
|
|
|
|
@Fabsn: Eine Sache ist mir nicht ganz klar:
1) Geht es dir darum, wie du die View für die Rechteverwaltung (Backend*) aufbaust?
2) Oder darum, wie die eigentlichen Seiten (Frontend*) basierend auf den Rechten dargestellt werden?
* Backend und Frontend entsprechend der Enduser-Definition**: Website und Admin-Bereich
** Hier muss man ganz klar zwischen Enduser- und Software-Entwickler-Definition unterscheiden. Hier im Thread ist letzteres gebräuchlich. Gleichzeitig bringt es nichts, zu versuchen, die Enduser umzuerziehen.
@Tenz: Es gibt die Code- und PHP-Tags, mit denen Code etwas übersichtlicher dargestellt werden kann:
| |
| Code: |
OptionType<SelectFromPreset>:
[
OptionValue:[],
key: String,
id: PositiveInteger,
displayDescription: String,
displayName: String,
maxOptions: PositiveInteger
]
OptionValue<Type>:
[
displayValue<String>,
value<Type>
] |
|
| |
| PHP: |
<?php
OptionType<SelectFromPreset>:
[
OptionValue:[],
key: String,
id: PositiveInteger,
displayDescription: String,
displayName: String,
maxOptions: PositiveInteger
]
OptionValue<Type>:
[
displayValue<String>,
value<Type>
]
?>
|
|
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von cms am 26.08.2021 16:02]
|
|
|
|
|
|
|
|
|
Also das System besteht natürlich aus Model, View und Controller.
Beispielhaft vier Bereiche
- Controller/LanguagesController
- Model/Table/LanguagesTable
- Model/Entity/Language
- entsprechenden Views aus templates/Languages
- Controller/NewsController
- Model/Table/NewsTable
- Model/Entity/News
- entsprechenden Views aus templates/News
- Controller/UsersController
- Model/Table/UsersTable
- Model/Entity/User
- entsprechenden Views aus templates/Users
- Controller/UserGroupsController
- Model/Table/UserGroupsTable
- Model/Entity/Usergroup
- entsprechenden Views aus templates/Usergroups
Egal was im System passiert: es wird immer eine AuthenticationMiddleware gestartet. Diese überprüft, ob der Besucher eingeloggt ist.
Wenn nicht, gibt's einen Redirect zur Loginmaske.
Wenn ja, holt diese Middleware die Daten des Nutzers aus der DB-Tabelle users.
Users haben über eine Assign-Tabelle eine Verbindung zu Usergroups. Usergroups haben eine Verbindung zu einer DB-Tabelle UsergroupPermissions, für die es keine separaten Views und keinen Controller gibt.
Die dort hinterlegten Daten sehen so aus:
Damit stehen alle zugewiesenen Permissions für alle zugewiesenen Gruppen des aktuellen Users in der Middleware zur Verfügung.
Beim Aufruf von /news/add passiert erstmal alles, was in 'nem normalen MVC so passiert. Es werden verschiedene Klassen und Configs geladen, Routen interpretiert blablubb und dann landet man in Controller/NewsController::add()
Als Entwickler entscheide ich nun, ob ich für diese Methode einen Zugriff überprüfen möchte. Wenn, dann nutze ich dafür eine weitere Middleware, die bereits eine NewsPolicy geladen hat.
Diese NewsPolicy besteht z. B. aus folgenden drei Permissionsdie durch die Spalte "identifier" in der UsergroupPermissions-Tabelle entweder erlaubt oder verboten werden.
Ich kann also nun mit $middleware->checkPermission('create') in der Methode überprüfen, ob der aktuelle User darauf Zugriff hat oder nicht.
Oder ich entscheide mit der gleichen Zeile in der View zu news/overview, ob ich einen Button zum Anlegen einer neuen News anzeige oder nicht.
Oder ich entscheide in Model/Table/NewsTable::save(), ob der User ein Entity speichern darf, wenn es neu ist. Oder, falls es ein existierendes Entity ist, ob der User "fremde" Einträge speichern darf, in dem ich $entity->user_id mit $identity->id vergleiche.
Soweit ist - hoffe ich - alles klar. Ich hab mich für den Weg über Policies und Permissions entschieden, weil ich nicht für jede Action eines Controllers oder für jeden Methode eines Models ein eigenes Zugriffsrecht definieren möchte, manchen Methoden oder Controllern gar keine Rechteprüfung aufzwingen will, und so auch an verschiedensten Stellen des Systems ganz spezifische Berechtigungen abfragen kann.
Gibt noch ein paar andere Situationen, in denen mir dieser Weg am hilfreichsten vorkommt aber das geht zu sehr ins Detail.
----
Eine Policy stellt verschiedene Permissions zur Verfügung. Dabei ist aber einer Permission nicht direkt bewusst, wo sie eingesetzt wird. Sie ist eben nicht an die Usergroups gebunden sondern kann auch für Users direkt, oder für Customers genutzt werden. Mir fallen auch hier noch andere Situationen ein, in denen ich sowas gebrauchen kann, aber auch das geht erstmal zu weit.
----
Nun die urspüngliche Situation nochmal von einer anderen Richtung beschrieben:
Beim Anlegen/Bearbeiten von Usergroups werden alle Policies und damit auch alle Permissions geladen und dafür Formularfelder angezeigt, womit der User (der eben schon Zugriff auf die Usergroups und damit die UsergroupPermissions hat) bestimmen kann, welche "Bereiche" für eine Gruppe zugänglich sind - oder eben nicht.
Hier lag mein ursprünglicher Denkfehler bzw. mein falscher Ansatz.
Die Permission selbst hat vorgegeben, welche Formularfelder angezeigt werden. Damit hatte man also keine Möglichkeit für die Verwaltung der UsergroupPermissions andere Felder anzuzeigen als für CustomerPermissions oder die Reihenfolge von input[type="radio"] zu ändern, wenn man ein neues "Backend-Theme" nutzen möchte, ohne dafür den Code anzupassen. Und es hat natürlich auch keine Sicherheit gebracht, dass die Datenbanktabelle, in die die Werte letztlich gespeichert werden, diese auch genau so übernimmt, wie sie die Permission in den value-Attributen der Felder ausgibt.
----
Der richtige(re) Weg sieht nun so aus, dass für jede Permission ein Partial geladen wird. Dabei kann entweder eine eigene Datei für jeden Bereich, wo eine Permission genutzt wird, verwendet werden oder es wird halt die Default-Datei verwendet
templates/element/(<subdir>/)?permission/single_choice.php
templates/element/(<subdir>/)?permission/multiple_choice.php
Das heißt zwar, dass die Permission nun initial die Werte zur Verfügung stellt, zwischen/aus denen der User auswählen kann - z. B. "ja" (1), "nein" (0) oder "mir egal" (NULL) - aber weder weiß, noch entscheidet, in welche Datenbanktabelle bzw. -spalte und als welcher Datentyp diese gespeichert werden oder mit welchem name-Attribut die Formularfelder abgeschickt werden. Muss ja auch nicht, denn:
Eine Permission braucht um einen Zugriff zu überprüfen letztlich "nur" eine Liste aus vefügbaren Berechtigungen.
Dabei weiß die Permission selbst, welche Werte sie zur Verfügung stellt und kann nur anhand dieser und der in sich definierten Logik überprüfen, ob der Zugriff erlaubt ist oder nicht.
Es ist also zwingend notwendig, dass UsergroupPermissionsEntity die Daten so speichert - oder zumindest so an die Permission zur Überprüfung zurückgibt - dass diese was damit anfangen kann. Aber im schlimmsten Fall funktioniert "einfach nur" eine Berechtigung nicht richtig und der Default-Zustand (im Backend immer 403) greift.
Ergibt das Sinn?
|
|
[Dieser Beitrag wurde 7 mal editiert; zum letzten Mal von Fabsn am 26.08.2021 16:57]
|
|
|
|
|
|
|
|
|
Das ergibt Sinn - letztendlich ist die Frage wohl welches level an Modularität du brauchst/brauchtes/anstrebst und wie autark das Admin-Backend durch das UI selber erweiterbar ist. Für ne Baukastenlösung oder Rechteverwaltung auf Feld-Ebene (z. B. wer news zwar schreiben aber keine tags vergeben darf) musst du natürlich extremer decouplen und abstrahieren als für den spezifischen Zugriff gescoped auf eine komplette Domain (user, news, etc).
Bist du denn zufrieden mit der Lösung?
Und worin unterscheidet sich jetzt z. B. das single_choice template für permission X von dem single_choice template für permission Y?
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von Tenz am 26.08.2021 17:40]
|
|
|
|
|
|
|
|
|
| | Zitat von Tenz
Für ne Baukastenlösung oder Rechteverwaltung auf Feld-Ebene (z. B. wer news zwar schreiben aber keine tags vergeben darf) musst du natürlich extremer decouplen und abstrahieren als für den spezifischen Zugriff gescoped auf eine komplette Domain (user, news, etc).
Bist du denn zufrieden mit der Lösung? | |
Sie erlaubt mir, zumindest in der Theorie in meinem Kopf, dass ich Zugriffsrechte anhand von (zusätzlich) hinterlegbaren Settings überprüfen/einschränken kann. Zum Beispiel eben das Anlegen/Bearbeiten von News, die sich nur in bestimmten Kategorien befinden. Wobei ich dann eben nicht für jede Newskategorie erstmal eigene Rechte definieren und dann vergeben muss.
Usergroup 1 kann alle News pflegen
Usergroup 2 kann alle News sehen aber nur News aus Newskategorie-ID 2 und 3 bearbeiten
Usergroup 3 kann nur News anlegen, die automatisch in Newskategorie-ID 5 landen
Das ist schon deshalb wichtig, weil ich, mal davon ausgehend dass es mal ein Livesystem wird, nicht erst alle Newskategorien anlegen lassen kann, ehe ich dafür im Code Zugriffsrechte definieren kann. Und trotzdem kann man sie im Backend dann frei wählen, sobald die Kategorien verfügbar sind.
| | Zitat von Tenz
Und worin unterscheidet sich jetzt z. B. das single_choice template für permission X von dem single_choice template für permission Y?
| |
Die Permissions nutzen erstmal die gleichen Templates. Allerdings könnte die single_choice für Permission news::create drei Werte als Radio-Inputs darstellen, während eine andere Permission 7 Werte bereitstellt und die dann als <select> dargestellt werden. 'ne andere Permission könnte auch eine SingleChoice sein aber ein input[type="number"] sein, das festlegt, wie viele Bilder ein User pro Tag in die Medienverwaltung hochladen oder wie groß die Datei maximal sein darf.
//Das mit Single- bzw. MultipleChoice ist aber auch erstmal so ein fixer Gedanke gewesen und betrifft wohl auch in Zukunft erstmal nur Settings, die wiederum unter Permissions liegen und dann dort die Formularfelder mit beeinflussen können oder genutzt werden, um Checks davon abhängig zu machen.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von Fabsn am 26.08.2021 20:35]
|
|
|
|
|
|
|
|
|
Hallo zusammen,
Ich habe hier eine etwas andere Frage an euch.
Aktuell gibt es in unserer codebasis viele boolsche konfig flags (an die 15.000), welche auch in der Datenbank vorhanden sind und über das gui geändert werden können.
Manche sind klassische Zugriffsberechtigungen wie „darf derjenige etwas ändern/Neuanlagen“ anderen sind zum steuern des Verhaltens.
Nun ist dies im Code historisch bedingt, durch viele unterschiedliche Implementierungen integriert, sowohl der boolschen Abfrage der flags als auch der Änderung.
Plus es werden auch noch einige dieser flags in globale buffer gelegt (um dann sowas wie meinbuffer[125] == ‚1‘ abzufragen, angeblich wegen Performance Gründen)
Zusätzlich gibt es in den prueftoutinenen auch noch 3 caches dieser flags, damit nicht jedes mal von der Platte gelesen werden muss)
Nun hat eine Änderung unseres Managers (der übrigens pro globale buffer zu Performance Optimierung steht) dazu geführt, dass ein Teil der Software plötzlich einen negativen Performance Hit von 800% abbekommen hat.
Grund ist, dass bei Änderung eines konfigflags einfach der gesamte Cache weggeschmissen wird + diese „meinbuffer“ neu aufgebaut werden (somit viele kleine Zugriffe auf die Platte).
Mein Vorschlag war nun, das mal sauber zu machen, ergo ein gemeinsames Interface/klasse neu schreiben.
Er war dagegen (tw. verständlich, da es eine sehr große Änderung wäre) und hat stattdessen vorgeschlagen, mittels weiteren globalen Cache zu prüfen, ob sich überhaupt an den speziellen konfigflags, die auch in die buffer geschrieben werden, was geändert hat und nur dann das Verhalten der Methode zu ändern.
(ergo sowas wie
If (mapDerSpeziellenKonfigFlags[„bla“] == true)
FunktionZumCacheNeuAufbauen(True);
Else
FunktionZumCacheNeuAufbauen();
Und an mehrer stellen diese globale map befuellen)
Ich war stark dagegen, weil es nur noch mehr zur Verwirrung führt.
Allerdings ist es für Ihn fast die einzige effektive Methode in diesem Fall, da wir ansonsten zu viele Fehler riskieren lt. Seiner Aussage.
Wie würdet Ihr mit solch einer Situation genau umgeben?
|
|
|
|
|
|
|
|
|
|
|
Rewrite in Rust.
Nein, natürlich versuchen durch eine saubere Implementierung zu ersetzen.
|
|
|
|
|
|
|
|
|
|
|
|
Schon immer wieder erstaunlich, was für Lösungen unsere Industrie hervorbringt
|
|
|
|
|
|
|
|
|
|
|
|
Konfig via 15.0000 bools. Huiuiuiui.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich glaub es wird Zeit den ersten der 3 Briefe zu öffnen
|
|
|
|
|
|
|
|
|
|
|
| | | Wie würdet Ihr mit solch einer Situation genau umgeben? | |
Generell muss "der Manager" verstehen, dass es hier ein ziemliches Problem gibt und das zu beheben kostet halt. Dann kann man sich überlegen wie man das angreift. So rein von deiner Beschreibung her könnte man nen Stufenplan formulieren:
1. Alle meinbuffer und elbuffer loswerden, sodass direkt auf die Implementierungen zugegriffen wird
2. Ein einheitliches Interface dazwischen klemmen
3. Und dann auf einen einheitlichen Speicher dahinter schwenken
4. Schauen ob der Caching-Wahnsinn jetzt noch wirklich nötig ist
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 28.08.2021 11:46]
|
|
|
|
|
|
|
|
|
Was ist das denn für eine in Anwendung, die 15000 bool Flags braucht? 
|
|
|
|
|
|
|
|
| Thema: Software-Entwicklung 0 ( new SammelThread() ) |
|
