"
You must be at least this tall to edit this property"
So oder ähnlich.
Folgende Geschichte: Meine Anwendung hat nicht
den Benutzer, sondern verschiedene Rollen. Der eine kann mehr, der andere weniger. Das haut hier niemanden mehr vom Hocker. Eine Einschränkung jedoch im Vorhinein: Ich habe weder genug Gehirnmasse noch Zeit um eine vernünftige
ACL (wie man es von Dateisystemen wie NTFS kennt) umzusetzen. Ich dachte daran, Benutzerrollen nach einer numerischen Größe sortierbar zu machen.
Beispiel:
Code:
root = 100
support = 90
kundeMainteance = 50
kundeQualified = 30
kundeStandard = 10
Gerne auch mit
5..1
für weniger große Zahlen.
Was bringt mir nun diese Sortierung? Ich dachte daran, allen einstellbaren Properties einer Klasse ein Security-Attribut mit den Eigenschaften
canView
und
canEdit
mitzugeben.
Ein im Alltag wenig interessantes Heizgedöns hätte ein
canRead=30
und
canEdit=50
: Erst der Schichtführer und alle "darüber" können nachsehen, wie es denn mit solchen Werten steht, der normale Bediener bekommt diesen Wert nie zu sehen. Die Heizung stärker befeuern oder drosseln kann nur jemand mit einem "Score" von mindestens 50.
Meine Frage:
Wie speichere ich nun am besten, wer was tun kann? Ich sehe drei Möglichkeiten:
- Ich gebe den Objekt-Properties über Attribute ihre beiden minimal nötigen Werte für canView und canEdit mit. Hier könnte schon einmal stören, dass alle Instanzen nun immer auf die gleichen Werte festgenagelt sind aber damit kann ich leben.
- Ich lege eine Tabelle an in welcher ich für jeden Benutzer explizit eine Rechte aufführe: Beispielsweise sage ich "kundeStandard - kann nicht - ändern - TMeineKlasse.meineProperty". Weiterführend könnte ich sogar sagen "kundeQualified - kann - ändern - TMeineKlasse.meineProperty - MINDESTENS 10% - HÖCHSTENS 90%".
- Eine Kombination aus beiden: Mittels Attributen im Quelltext lege ich fest, was gängige Benutzerrechte sind und wenn es abgeändert werden muss können die Standardwerte durch eine Datenbank überschrieben werden.
Die Nachteile der drei Möglichkeiten die ich sehe sind folgende:
- Erlaubt eben nicht mehr als Verstecken und Sperren. Keine Kunsstücke wie dass der Kundenadministrator in einem kleineren Intervall Werte ändern darf als bsp. unser Support.
- Fehler und unerwartetes Verhalten ist vorprogrammiert wenn bei der Installation ein paar Zeilen in der Datenbank unter den Tisch fallen. Möchte ich einen neuen Benutzer "zwischen" zwei existierenden Rollen hinzufügen, muss ich wieder alles explizit in der Datenbank festlegen. Füge ich neue Klassen hinzu, muss ich diese auch in die Datenbank aufnehmen. Horror.
- Natürlich wieder auf aufwändigsten zu realisieren
Ich habe so etwas in der Richtung noch nie gemacht und kann es nicht mehr länger aufschieben. Außer Panik im Kleinhirn sind hierzu noch nicht viele Gedanken entstanden. Bin ich vielleicht jetzt schon auf dem falschen Dampfer? Oder könnte man es so durchziehen?