Freezeyou

Hallo an alle,

Ich hab eine etwas ausführlichere Frage zur Modulrennung und Rechteverwaltung bzw Rechteprüfung .
Der Aufbau ist bisher so gestaltet (ich gehe hier nicht auf Details an, wenn ich zuwenig Info liefere
bitte melden )

• eine Basisklasse (zuständig für Initialisierung von Registry-Objekten, Konfiguration einlesen, usw)
• verschiedene Models (User, DBHandler, Logger, usw)
• mehrere Modulklassen

Die Basisklasse enthält einen FrontController der die Anfragen verwaltet und an die einzelnen Module
weiterleitet (diese Module sind als Klassen gestaltet)

Mit dieser Aufteilung soll es möglich sein mit mehreren Leuten an dem Projekt zu arbeiten
Sprich: Der Entwickler X hat ein Modul(z.B. Benutzerverwaltung) als Aufgabe und kann dazu vorhandene
Models verwenden (=> Klasse User)

Die verschiedenen Aktionen des Programms werden bisher nur über eine $_GET Variable übertragen
(sprich index.php?action=shownews würde News anzeigen)

Um die Module unabhängiger von der Basisklasse zu gestalten würde ich jetzt eine zusätzlichen
Parameter in der URL anfügen: index.php?module=news&action=show
Damit würde ich dann den FrontController aufteilen (einmal in der Basisklasse, danach noch
eine Methode im entsprechenden ModulController).

Zur zweiten Frage (die damit zusammhängt):
Bisher (alter Code) lief die Rechteverwaltung so, das bei jeder einzelnen Aktion am Anfang eine if()-Abfrage
stand nach folgendem Prinzip:

Das hätte ich gerne anders geregelt, aber wie macht man das am besten?
Wenn möglich soll das (vorerst) nicht in die Datenbank ausgelagert werden, da es quasi nur 2 Typen user gibt.
(Administratoren und normale Nutzer)
Meine erste Idee war die Rechte in der Basisklasse als mehrdimensionales Array zu hinterlegen, das geht
aber nur dann wenn man die Rechte pro Modul bestimmen kann und nicht pro durchzuführender Aktion.

Also müsste jede Modulklasse die Daten darüber enthalten welche Aktionen welcher User durchführen darf.
Ich bin mir bisher nur unsicher mit welcher Datenstruktur man das am effektivsten hinbekommt...wie gesagt,
weitere Aufteilung ist bisher nicht nötig von daher würde ich vorerst auf eine entsprechende Tabellenstruktur
verzichten.

Macht das Vorgehen Sinn oder gibt es bessere/andere Ansätze?

Mfg
Ralf

Mister Ad

Manko10

Hi,

ja, so etwas nennt sich in der Regel ActionController und ist nicht gerade unüblich. Damit das aber vom Look her etwas freier wird, würde ich das so machen: index.php/news?action=show. Den Controllernamen (news) kannst du dann über $_SERVER['PATH_INFO'] auslesen.

Bei der Rechteverwaltung gehst du sehr starr vor. Du hast eine hübsche kleine Methode, mit der du prüfst, ob jemand Admin ist. Wenn du aber später weitere Gruppen hinzufügen willst, wirst du ins Schwimmen kommen. Ich würde den Kram über Beziehungen lösen und in Klassen kapseln. Ich halte es nicht für sinnvoll, die Berechtigungen in die User-Klasse zu schreiben, da du hier schnell an Grenzen stößt und auch nicht stark genug kapselst.
Wenn du dann bei fehlender Berechtigung den gesamten Controller sperren willst, musst du den Check schon im Konstruktor einbauen. Wenn du einzelne Actions sperren willst, in der zugehörigen Methode. Du kannst in deinem Interface aber auch eine Methode bool hasPermission() einbauen, die automatisch vom Frontcontroller aufgerufen wird. Wichtig ist nur, dass du hier wirklich mit Interfaces arbeitest, um die Kompatibilität zu gewährleisten.

__________________
Refining Linux Advent Calendar series “24 Outstanding ZSH Gems”

dr.e.

Hallo zusammen,

ich würde noch einen Schritt weiter gehen und die Verwaltung der Rechte (=Funktionsrechte; nicht zu verwechseln mit Rechte auf Objekte einer Anwendung) noch generischer gestalten. Hier findet sich dazu ein UML, das dem Benutzer über eine Rolle Permissions zuweist, die in einem Controller abgefragt werden können. Das hat den entscheidenen Vorteil, dass ich nicht starr an Methoden wie isAdmin() gebunden bin, sondern a) granularer abfragen kann, welche Funktionsberechtigungen ein Benutzer hat und b) eine Änderung meiner Datenstruktur (=Struktur der BenutzerVerwaltung und der Rollen / Permissions) nicht gleichzeitig mit einem Refactoring der API einhergeht.

Was das Thema Workflows von Anfragen angeht, könnten dich vielleicht die UML-Diagramme Page-Controller und Front-Controller interessieren. Letzteres bietet dir die Möglichkeit beliebige Actions ausführen zu lassen, die dir z.B. ein Model aufbauen, das Informationen wie "Ist der Benutzer nun eingeloggt?" und "Was darf er eigentlich tun?" bereits ganz am Anfang des Requests geklärt werden können. So kannst du bei fehlender Berechtigung bereits vor der Ausführung von eigentlichem Programmcode auf eine andere Seite weiterleiten oder einen definierten View mit einer Fehlermeldung statt einer Bearbeiten-Maske anzeigen. Dies ist allerdings nur dann möglich, wenn du die Business-Schicht (Model einer Anwendung) nutzt um die Präsentation der Anwendung zu beeinflussen/zu steuern. Anregungen dazu finden sich hier.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Freezeyou

Vielen Dank an euch beide für die ausführlichen Rückmeldungen.

Um später in der Rechteverwaltung flexibel zu bleiben habe ich jetzt
eine Klasse UserRightsManager eingeführt, die für das entsprechende
Modul und die entsprechende Action festlegt ob der User berechtigt ist.

Damit halte ich den Änderungsaufwand erstmal gering und hätte später
die Möglichkeit statt einer einfachen Prüfung z.B. eine
rollenbasierte Authentifizierung hinzuzufügen. Das erschien mir erstmal am sinnvollsten.

Nachteil davon ist natürlich das ich jede Action der Anwendung in dieser Klasse
registrieren muss.

Aber was wäre wenn ich eine rollen- oder gruppenbasierte Authentifizierung einbauen wollen würde?
Wenn ich diese Daten in der Datenbank halten würde müsste ich bei einer neuen Action bzw
einem neuen Modul der Anwendung doch auch die entsprechenden Berechtigungen festlegen,
also hätte man doch keinen entscheidenden Nachteil wenn man die Berechtigungen auf
einer Ebene über dem Modul kenntlich machen muss?

Oder macht es mehr Sinn pro Modul (Modul kann man in diesem Kontext erstmal als Controller-Klasse
verstehen die bestimmte Anfragen auswerten kann) die Berechtigungen festzulegen?

Dr. E. die entsprechenden Diagramme und Texte habe ich mir durchgelesen.
Soweit ich das nachvollziehen konnte scheint alles sehr gut durchdacht.

Ich werde mir demnächst mal einen Gesamtüberblick über dein Framework verschaffen,
im Moment möchte ich den Änderungsaufwand aber erstmal nicht größer als nötig machen,
auch weil ich mich auf dem Gebiet Softwarearchitektur nicht auskenne.

Könnt ihr gute Bücher zum Thema Softwarearchitektur empfehlen?

dr.e.

Hallo,

Was soll denn sein? Du hast eine zentrale Komponente, die dir die Frage: "Ist der Benutzer für diese Aktion authorisiert oder nicht?" bzw. "Darf ich mich bei dieser Anwendung einloggen?" beantworten kann. Damit bist du bereits fertig gerüstet diesen Mechanismus in die entsprechenden Module einzubauen. Ich sehe da kein Hinderniss.

Mein Ansatz wäre gewesen, das Usermanagement einfach als zentrale Komponente aller Module zu sehen - quasi eine Querschnittsfunktion. Damit muss natürlich die Definition der Rollen und Permissions auch in der Datenbank angelegt sein. Das ist jedoch immer so, denn generische Rollen wird man schlecht anlegen können. Verwendest du jedoch eine zentrale Datenbank, so kannst du für das Modul ja ein Setup erstellen, das die notwendigen Rollen und Permissions zusammen mit der Tabellenstruktur anlegt.

Sicher. Naturgemäß wird jedes Modul seine eigenen Aktionen haben, die es zu restriktieren gilt. Verwaltest du eine Bildergalerie mit Funktionen wie
- Galerie erstellen, bearbeiten, ...
- Ordner erstellen, bearbeiten, ...
- Bild-Upload
- Bild-Bearbeiteung
ist das sicher in anderer Form zu handhaben als ein Gästebuch oder eine einfache News-Verwaltung. Das ist eben der Vorteil einer generischen Rollendefinition über Permissions, da du dann sehr flexibel sagen kannst, wer was darf oder auch nicht.

Wenn du da Diskussionsbedarf hast, steht dir php.de und das APF-Forum jederzeit zur Verfügung. Als Einsteiger ist der Thread forum.adventure-php-framework.org [de] • Thema anzeigen - Hilfe für APF-Neuling auch ganz gut als Lektüre geeignet. Weiterhin stehen dir einige Tutorials zur Verfügung, die auch nochmal Themen der Software-Architektur erklären. Grundsätzlich kannst du jedoch auch bereits implementierte Komponeten trotz Einsatz des APF weiter verwenden, eine smarte Migration ist also ohne weiteres möglich.

Unter Literatur :: Adventure PHP Framework (APF) habe ich einige aufgeführt, die ich für gut erachte. Sofern du kein Problem mit anderen Programmiersprachen hast, kannst du auch mal ein JAVA-Architektur-Buch lesen, in diesem Bereich gibt es schon deutlich mehr Angebote. Als allgemeines Buch könnte auch Pattern-orientierte Software-Architektur . Ein Pattern-System: Amazon.de: Frank Buschmann: Bücher für dich interessant sein. Frank Buschmann habe ich bereits auf der OOP gehört und war von seinen Vorträgen mit Kevlin Henney begeistert.

Any questions left?

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~