Registriert seit: 26. Mai 2004
3.159 Beiträge
|
Rechtemanagement in eigener Anwendung - Was ist sinnvoller?
25. Feb 2008, 09:37
Hallo,
der Titel meines Threads soll schon andeuten, dass es um das Rechtemanagement in einem selbst geschriebenen Programm geht. Hierbei ist eigentlich egal um welches Thema es sich bei der Applikation dreht, es geht nur darum, dass diverse User bestimmte Funktionen ausführen dürfen und andere, aufgrund deren Rechte, eben nicht.
Ich habe bisher vier Ansätze gefunden, wie ich so etwas implementieren könnte. Hierbei stelle ich nun zunächste die simplen Methoden vor, d.h. man kann Rechte eines Benutzer, der gerade mit einer Anwendung arbeitet, nicht ändern. Die zweite eher komplexerer Möglichkeit umfasst dann auch die Änderungen der Rechte während der der Nutzer am Programm arbeitet. Ich hoffe, dass es aus meiner folgenden Erläuterung klar wird, warum ich einmal eine Betrachtung ohne die Änderung und einmal mit der Änderungsmöglichkeit mache.
Ohne Änderung: - Zum einen könnte man die Rechte fest im Programm definieren. Die Rechte müssen eh zuvor schon feststehen, da man schon eine Menge an Funktionen hat und diese dann entsprechend mit Rechten versieht. Ein Benutzer wird hierbei einer Gruppe zugewiesen und diese hat wiederrum die Rechte eine Funktion auszuführen oder nicht. Ein Benutzerprofil muss sich somit nur merken, in welcher Gruppe "es liegt" und nicht seine einzelnen Rechte.
Die Abfrage, ob eine Methode ausgeführt werden darf oder nicht, würde ich über eine globale Methode checkRight() laufen lassen, welcher ich den Namen der Methode (oder ähnliches, bsp. eine ID) und die Gruppe übergebe. Diese liefert mir anschließen TRUE oder FALSE (evtl. auch eine größere Menge an Rückgabewerten), welche aussagen, ob die Applikation die Methode ausführen darf oder nicht.
[Start] -> [Aufruf Methode] -> [checkRight()] -> [ausführen, verweigern]
- Zum Anderen könnte ich, beispielsweise in einer Datenbank, Benutzerprofil erstellen, in der auch die einzelnen Rechte des Benutzers abgelegt sind (*). Wenn ich die Applikation starte, dann werden die Daten inkl. den Rechten geladen. Will der User z.B. Drucken, dann soll das Programm prüfen, ob er dies, aufgrund der Rechte, die er hat, überhaupt darf und die Ausführung zulassen oder eben auch nicht. Hierbei ist eben zu beachten, dass die Rechte schon im Programm, innerhalb einer Klasse, vorliegen und nicht geladen werden.
[Programmstart] -> [Rechte laden] -> [Aufruf Methode] -> [Recht prüfen] -> [ausführen/verweigern]
* Von mir aus stehen die Rechte auch in einer anderen Tabelle, wobei dann nur eine 1:1-Beziehung entstehen würde, was eine Auslagerung nicht sinnvoll machen würde, da ich dann immer zwei Tabellen anfassen müsste.
Mit Änderungen der Rechte: - Die Rechte werden hierbei nicht im Programm selbst definiert, sondern jedes Mal, wenn der Benutzer eine Methode ausführen will, lädt die Methode checkRight() das passende Recht nach (z.B. aus einer DB) und prüft dann anhand der Gruppenzugehörigkeit, ob die Methode ausgeführt werden darf oder nicht.
Das Diagramm dazu sieht dann wie folgt aus:
[Start] -> [Aufruf Methode] -> [loadRight() + checkRight()] -> [ausführen, verweigern]
- Will ein Benutzer eine Methode aufrufen und sind die Rechte in einem Benutzerprofil gespeichert, so wird jedes Mal das Recht in seinem, im Programm gehalteten Benutzerprofil aktualisiert und entsprechend wie oben dann die Abfrage gemacht. An dieser Stelle können die Rechte als Eigenschaften in seinem Profil wegfallen und durch get-Methoden ersetzt werden, d.h. ich frage jedes Mal live seine Recht ab.
Das zugehörige Diagramm ist nun das folgende
[Programmstart] -> [Aufruf Methode] -> [loadRight() + Recht prüfen] -> [ausführen/verweigern]
Meine Frage ist hierbei nun, welche Methode der Implementierung ist sinnvoller und flexibler?! Welche Methode wirft eurer Meinung nach mehr Probleme auf? Welche hat mehr Vorteile? Hierzu sollten aber die beiden Modelle im Bezug auf die Änderung der Rechte während der Laufzeit unterschieden werden!
Mit freundlichen Grüßen
der Hai
»Remember, the future maintainer is the person you should be writing code for, not the compiler.« (Nick Hodges)
|