AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

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
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#1

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
Der schöne Günther

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

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
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#3

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.659 Beiträge
 
FreePascal / Lazarus
 
#4

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.492 Beiträge
 
Delphi 7 Enterprise
 
#5

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
 
#6

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
Benutzerbild von Union
Union

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

AW: Benutzerrollen, Rechte

  Alt 6. Aug 2013, 11:11
Es handelt sich um eine erweiterte TActionList mit erweiterten TAction Elementen. Die Liste und die Elemente haben eine Security-ID sowie zusätzliche Events. Hat die Action einen Zugriffsevent, so wird dieser ausgeführt ansonsten der aus der Actionlist. So kann man eine allgmeine Prüfung für alles haben, es bei einzelnen Actions aber im Bedarfsfall über einen anderen Event steuern. Im Event wird dann einfach der Zugriff gesetzt. Abhängig davon wird dann Enabled gesetzt.
Ibi fas ubi proxima merces
sudo /Developer/Library/uninstall-devtools --mode=all
  Mit Zitat antworten Zitat
Antwort Antwort

 

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 22:24 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz