AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Benutzerrollen, Rechte

Offene Frage von "Union"
Ein Thema von Der schöne Günther · begonnen am 5. Aug 2013 · letzter Beitrag vom 6. Aug 2013
Antwort Antwort
Seite 1 von 2  1 2   
Der schöne Günther

Registriert seit: 6. Mär 2013
5.296 Beiträge
 
Delphi 10 Seattle Enterprise
 
#1

Benutzerrollen, Rechte

  Alt 5. Aug 2013, 14:07
"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:
  1. 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.

  2. 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%".

  3. 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:
  1. 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.

  2. 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.

  3. 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?
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
2.843 Beiträge
 
Delphi 2010 Enterprise
 
#2

AW: Benutzerrollen, Rechte

  Alt 5. Aug 2013, 14:31
Was Dir vorschwebt, haben wir in umgekehrter Form in einem Projekt als UserSkill implementiert. Das Recht selbst hat einen (vom Kunden) definierten Skillwert, der User einen initialen, der vom Kunden (oder wie auch immer automatisch nach gewisser Zeit) erhöht/geändert werden kann.
Das ist noch mit anderen Möglichkeiten kombiniert (z.B. "eigenes Passwort eingeben" - zum Aufwachen)
Das ganze System kann (vom Kunden!) beliebig komplex gestaltet werden.
Auf Clientseite ist das in den Basisklassen fest verankert und muss nicht geändert werden bei neuen / anderen Inhalten.
Für harte Rechte, also SQL Rollen/-Rechte haben wir das je Maske / Datenquelle ebenfalls in einer Basisklasse gekapselt, allerdings nicht auf Feldebene.
Zusätzlich gibt es eine Klasse für clientseitige "Sonderrechte" (z.B. "kann das Drucken" oder "..importieren.."). Sie prüft über DB seitige Definitionen, ob eine bestimmte Funktion ausgeführt werden darf. Da das Sonderrecht idR. mit einer ausprogrammierten Klasse im Client einhergeht, wird das hier gezielt abgefragt und ist so auch kein nennenswerter Zusatzaufwand.

Zu Deiner Idee:
Ich würde sagen, erstmal ok, aber ich stelle mir vor, dass in der Praxis kein User in einer unternehmesweiten "Fachlichkeit" überall einen bestimmten/gleichen Level hat/ erreicht.
Du bekommst also irgendwann Probleme, weil der Müller (der König aus dem Lager), die Feinheiten in der Produktion justiert...
Gruß, Jo
  Mit Zitat antworten Zitat
Benutzerbild von BUG
BUG

Registriert seit: 4. Dez 2003
Ort: Cottbus
2.094 Beiträge
 
#3

AW: Benutzerrollen, Rechte

  Alt 5. Aug 2013, 14:33
Würde Lösung 2 entsprechen:
Packe die Rechteverwaltung in ein Filter für die entsprechenden Objekte, das die Aufrufe filtert und im Verletzungsfall eine Exception wirft. Der "Nutzer" bekommt die geschützten Objekte aus einer Factory, die passenden Filter (evtl. mehrere) entsprechend seiner Rolle(n) erstellt.
Die Filter selbst können beliebig komplexe Einschränkungen überprüfen und ihre Eigenschaften (z.B. die möglichen Intervallwerte) könnten aus der Datenbank oder aus den Attributen (entsprechend Lösung 1) gelesen werden.
Intellekt ist das Verstehen von Wissen. Verstehen ist der wahre Pfad zu Einsicht. Einsicht ist der Schlüssel zu allem.
  Mit Zitat antworten Zitat
Benutzerbild von Union
Union

Registriert seit: 18. Mär 2004
Ort: Luxembourg
3.308 Beiträge
 
Delphi 7 Enterprise
 
#4

AW: Benutzerrollen, Rechte

  Alt 5. Aug 2013, 14:42
Wir haben hier auch Lösung 2 implementiert:
  • Benutzer
  • Benutzergruppen
  • Benutzerberechtigungen
  • Gruppenberechtigungen
  • Benutzergruppenmitgliedschaften
  • Gruppenmitgliedschaften

Dazu eine abgeleitete Actionlist mit entsprechendem erweiterten Property-Editor und ein kleiner Dialog zur Verwaltung der Benutzer, Gruppen und Mitgliedschaften. Das kannst Du natürlich auch genauso gut in einem anderen Basisobjekt regeln, es muss ja nur die ID der Berechtigung gespeichert werden. Damit ist dann fast jede Kombination möglich, ähnlich wie bei den Windows-Berechtigungen.
Ibi fas ubi proxima merces
sudo /Developer/Library/uninstall-devtools --mode=all
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.652 Beiträge
 
Delphi 7 Personal
 
#5

AW: Benutzerrollen, Rechte

  Alt 5. Aug 2013, 14:57
Wenn Du eine spielerische Lösung suchst würde ich mit Bitmustern arbeiten, ähnlich den Attributen von Dateinen. Mit 32 Eigenschaften kann man immerhin ne Menge erschlagen.
Die "große" Lösung wäre die Speicherung in der Datenbank, da kann der Kunde sich zu Tode konfigurieren, Du mußt nur nachschauen ob für die gewünschte Funktionalität auch eine Berechtigung vergeben wurde. Vielleicht noch ein paar Häkchen a la der admin darf Lesen und Schreiben und Briefe versenden, die die notwendigen Werte im Hintergrund setzen und gut ist. Bitte nicht vergessen, richtige DBs habe noch eine eigene Rechteverwaltung im Rucksack, die muß ggf. mit angepasst werden.

Gruß
K-H
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
5.296 Beiträge
 
Delphi 10 Seattle Enterprise
 
#6

AW: Benutzerrollen, Rechte

  Alt 5. Aug 2013, 15:31
Vielen Dank schon einmal für die schnellen Antworten!

Das Recht selbst
Das ist schonmal ein interessanter Ansatz. Es ist eigentlich perfekt für Aktionen die ausgeführt werden sollen wie "Drucke einen Report" oder "Pausiere die menscheneinsaugende Turbine". Ich dachte allerdings größtenteils an Settings, also reine Werte anzeigen und ggf. Editieren.
Ich verstehe nicht, was
Auf Clientseite ist das in den Basisklassen fest verankert und muss nicht geändert werden bei neuen / anderen Inhalten
genau beudetet. Ich müsste doch trotzdem ständig manuell nach einem passenden Recht suchen, schauen wie es um den aktuellen Nutzer bestellt ist und dementsprechend handeln. Wenn ich eine Klasse nun um neue Properties erweitere, muss ich doch auch ebenso viele neue Rechte hinzudichten? Oder habe ich was falsch verstanden?

in der Praxis kein User in einer unternehmesweiten "Fachlichkeit" überall einen bestimmten/gleichen Level hat/ erreicht.
Du bekommst also irgendwann Probleme, weil der Müller (der König aus dem Lager), die Feinheiten in der Produktion justiert...
Das stimmt, daran habe ich noch nicht gedacht. Die Software ist allerdings recht speziell, so unterschiedliche Qualifikationen sollten da nicht auftreten. Zumindest noch nicht...


Packe die Rechteverwaltung in ein Filter für die entsprechenden Objekte, das die Aufrufe filtert und im Verletzungsfall eine Exception wirft. Der "Nutzer" bekommt die geschützten Objekte aus einer Factory, die passenden Filter (evtl. mehrere) entsprechend seiner Rolle(n) erstellt.
Aber entweder müsste ich den Quellcode dieser Filterfabrik jedes mal anpassen, wenn sich an den Objekten etwas ändert, oder ich das Ding ist so flexibel, dass es Getter und Setter dynamisch zusammenbaut. Ein ganz schönes Monsterteil.


Das wäre mit Sicherheit die feine englische Art. Aber Benutzer in Gruppen stecken, Benutzerrechte überschreiben evtl. wieder Gruppenrechte, Benutzer in mehreren Gruppen - Das bekomme ich in gefordertet Zeit niemals hin, ich muss bei etwas einfacherem bleiben



Die "große" Lösung wäre die Speicherung in der Datenbank, da kann der Kunde sich zu Tode konfigurieren, Du mußt nur nachschauen ob für die gewünschte Funktionalität auch eine Berechtigung vergeben wurde.
Gerade das Nachschauen sieht für mich aus wie Gewitterwolken am Horizont. An den Objekten selbst wird sich über die nächste Zeit viel ändern, das kann ich riechen. Dieses Nachschauen möchte ich nicht manuell machen. Der Kunde bekommt eine neue Softwareversion, die Objekte haben etliche neue Properties, seine Config-Datenbank bleibt natürlich unangetastet. Jetzt haben alle neuen Dinge ein Default-Verhalten, bsp. von jedem les- und schreibbar.


Bonus:
Man sollte noch ausführen, dass die Anwendung aus mehreren, miteinander kommunizierenden Prozessen besteht. Im Endeffekt ist es eine Master-Anwendung (inkl. grafisches Frontend) mit mehreren Slave-Prozessen, die nur auf Anfragen antworten und nicht von sich aus sprechen. Aus diesen Prozessen möchte ich Werte auslesen und ggf. setzen. Und diese Prozesse sollen sich auch nicht mit Datenbanken herumschlagen.
Deshalb war (und ist) es mir immer noch sehr sympathisch, per Attribute im Quelltext standardmäßige Berechtigungswerte vorzugeben, der Benutzer soll das in der Master-Anwendung anpassen können.
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
2.843 Beiträge
 
Delphi 2010 Enterprise
 
#7

AW: Benutzerrollen, Rechte

  Alt 5. Aug 2013, 15:55
Ich verstehe nicht, was
Auf Clientseite ist das in den Basisklassen fest verankert und muss nicht geändert werden bei neuen / anderen Inhalten
genau beudetet. Ich müsste doch trotzdem ständig manuell nach einem passenden Recht suchen, schauen wie es um den aktuellen Nutzer bestellt ist und dementsprechend handeln. Wenn ich eine Klasse nun um neue Properties erweitere, muss ich doch auch ebenso viele neue Rechte hinzudichten? Oder habe ich was falsch verstanden?
Bei dem Abschnitt handelt es sich um das Skillsystem, es ist nicht bindend in der Anwendung, nur eben sehr vergleichbar zu Deinem (und halt umgekehrt).
Jede darstellbare/bearbeitbare Maske~Datenquelle kommt mit einer eindeutigen ID aus der DB (dynamisch). Die Datenzugriffsklassen erfragen nun per se den minimal geforderten Skill und den des Users. Unzureichende UserSkills werden schon von serverseite gar nicht ausgeliefert, was übrigbleibt (UserSkill höher als erforderlicher Maskenskill) wird auf Details geprüft.
Die Basisklasse braucht immer nur 3 Parameter zu prüfen (ID, Userskill~istwert, VorgabeSkill~minimaler Sollwert). Da muss nichts nachgepflegt werden, außer die Maske bietet eine Spezialfunktion, zu der es eine Skillregel gibt. Wie gesagt, die "Clientspezialfunktion" erfordert sowieso ein individuelle Implementierung, da tut die individuelle Skillabfrage nicht weh.

Zu Deiner letzten Anmerkung: Dein System müsste dann alle in Frage kommenden Berechtigungsfälle des Subsystems abfragen (die also kennen oder "besorgen" können) und ihm die Resultate mitgeben, damit dieses dann autark arbeiten kann.
Gruß, Jo
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.652 Beiträge
 
Delphi 7 Personal
 
#8

AW: Benutzerrollen, Rechte

  Alt 5. Aug 2013, 15:58
Gerade das Nachschauen sieht für mich aus wie Gewitterwolken am Horizont. An den Objekten selbst wird sich über die nächste Zeit viel ändern, das kann ich riechen. Dieses Nachschauen möchte ich nicht manuell machen.
Der Kunde bekommt eine neue Softwareversion, die Objekte haben etliche neue Properties, seine Config-Datenbank bleibt natürlich unangetastet. Jetzt haben alle neuen Dinge ein Default-Verhalten, bsp. von jedem les- und schreibbar.
Naja das ist doch ganz hübsch, nur wo ist das Problem des Nachschauens? für jede Funktionalität hast Du im allg. auch einen Namen dazu packst Du eine Berechtigung und einen Benutzer( und/oder eine Rolle) fettich.

Das mit dem "Config-Datenbank bleibt natürlich unangetastet" passt mir nicht, das klingt wie wasch mich aber mach mich nicht naß. Du Ihr sollt also beliebig komplexe Berechtigungsmodelle in Source gießen, und 2 Wochen nach Auslieferung steht der Kunde weinend auf der Matte und erzählt "so hab ich es aber nicht gemeint!"

Gruß
K-H
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
Benutzerbild von Union
Union

Registriert seit: 18. Mär 2004
Ort: Luxembourg
3.308 Beiträge
 
Delphi 7 Enterprise
 
#9

AW: Benutzerrollen, Rechte

  Alt 5. Aug 2013, 18:13
Das wäre mit Sicherheit die feine englische Art. Aber Benutzer in Gruppen stecken, Benutzerrechte überschreiben evtl. wieder Gruppenrechte, Benutzer in mehreren Gruppen - Das bekomme ich in gefordertet Zeit niemals hin, ich muss bei etwas einfacherem bleiben
So problematisch ist das nicht. Das basiert dann auf einer einzigen SQL-Abfrage:
Code:
select us.name,
      userrights.Rightid as UsRId,
      Grouprights.Rightid as GRRId,
      r1.Nr as UsRNr,
      r2.Nr as GrRNr
from "user" as us
left outer join userrights on userrights.userid = us.id
left outer join usergroups on usergroups.userid = us.id
left outer join grouprights on grouprights.groupid = usergroups.groupid
left outer join Rights r1 on r1.id = Userrights.rightid
left outer join Rights r2 on r2.id = Grouprights.rightid
where ucase(us.name) = :username
and r1.nr = :nr or r2.nr = :nr
Wenn diese Query etwas zurückgibt, hat der Benutzer :username die Berechtigung für :nr.
Ibi fas ubi proxima merces
sudo /Developer/Library/uninstall-devtools --mode=all
  Mit Zitat antworten Zitat
CarlAshnikov

Registriert seit: 18. Feb 2011
Ort: Erfurt
108 Beiträge
 
Delphi XE5 Enterprise
 
#10

AW: Benutzerrollen, Rechte

  Alt 6. Aug 2013, 10:34
Auch für mich ein sehr interessantes Thema. Habe leider inhaltlich nichts beizusteuern.

@Union könntest du deinen Ansatz mit der Actionlist etwas genauer erläutern? Ich denke mal, dass du so die Controls mit den entsprechenden Berechtigungen verbindest? Ich hoffe das führt hier nicht am Thema vorbei.
Sebastian
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 16:18 Uhr.
Powered by vBulletin® Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2020 by Daniel R. Wolf