|
Delphi-Version: 7
Benutzerrechte?
Wie werden eigentlich mit Delphi Benutzerrechte bestimmt? Meine Anwendung soll Benutzerverwaltung bekommen mit verschiedenen Benutzerrechten. Gibt's vielleicht irgendwo ein Manuell dazu?
Thx |
AW: Benutzerrechte?
Eigentlich genauso wie mit jeder anderen Programmiersprache auch ;)
Am Einfachsten durch entsprechendes Ausblenden von Funktionen/Menüpunkte beim Start der Anwendung. |
AW: Benutzerrechte?
Zitat:
Beim Start der Anwendung wird ein Anmeldeformular geladen, in das man Benutzername und Passwort eingibt, die als Hashwert in der zugehörigen Datenbank gespeichert sind. In der Benutzertabelle der Datenbank steht ein Verweis auf die Rechte-Tabelle: 0 = Administrator, der darf alles. 1 = Chef, der darf fast alles. 2 = Vorgesetzter, der darf ein bissel weniger als der Chef. 3 = Mitarbeiter, der darf nur das Nötigste. 4 = Besucher, der hat nur Leserechte und darf nix schreiben. Fängt nun ein neuer Mitarbeiter an, geht man zum vorgesetzten Abteilungsleiter, der darf neue Benutzer anlegen. Mitarbeiter dürfen das nicht. Zum Anlegen eines neuen Benutzers verwende ich dasselbe Formular wie bei der Anmeldung, nur daß zwei weitere Komponenten beim Anlegen bzw. Ändern sichtbar werden: das zweite Passwort-Edit (Passwort wiederholen) und die Combo mit den verfügbaren Rechten. Muß ein Benutzer geändert oder gelöscht werden, geht man zum Chef, denn nur der und der Admin dürfen das. Der Admin darf zusätzlich noch ein paar mehr Sachen, die die fachliche Kompetenz des Chefs übersteigen würden. Wie du das nun genau umsetzt, bleibt natürlich dir überlassen. |
AW: Benutzerrechte?
Zitat:
|
AW: Benutzerrechte?
Was genau verstehst du denn an obiger Skizze nicht? Oder anders gefragt: Was erwartest du jetzt? Quellcode?
|
AW: Benutzerrechte?
Such mal nach
 RBAC (Role Based Access Control). Im Gegensatz zu anderen gängigen Programmiersprachen/Frameworks (siehe z.B. C sharp RBAC oder RBAC node.js) sind mir für Delphi keine Beispiel-Implementierungen bekannt. |
AW: Benutzerrechte?
Ich habe es bei mir ähnlich wie Perlsau: Es gibt Benutzer und die gehören einer Gruppe an. Eine Gruppe hat einen numerischen Wert (zwischen 0 und 100) der ausdrückt, wieviel sie dürfen. Manche Dinge gehen ab einem Rechtewert von 30, andere ab 70.
Für komplexere Dinge hat mir schlicht die Zeit gefehlt. Der Ansatz hat auf jeden Fall den Schwachpunkt den ein schlauer Mann hier bestens auf den Punkt gebracht hat: Zitat:
|
AW: Benutzerrechte?
Man könnte z.B. ein Byte mit den Benutzerrechten mitschleppen und mit entsprechender Maskierung das Rechtelevel feststellen.
Gruß K-H |
AW: Benutzerrechte?
Ich speichere mir die Benutzerrechte eines Benutzers als Integer-Wert in der Datenbank. Der Wert wird dann beim Anmelden wieder in seine binären Bestandteile zerlegt. Die Zerlegung erfolgt mit Bitverschiebung. Wenn das niederwertigste Bit eine 1 ist, dann wird das entsprechende Recht hinzugefügt, ist es 0 dann eben nicht. Die möglichen Rechte sind in einem bzw. mehreren Type(s) hinterlegt. Die Rechte, die der Benutzer nach der Anmeldung bekommt, sind in einem Set of Permissions abgelegt.
Bei Bedarf kann ich auch gerne mal ein wenig Quellcode posten, der diese Vorgehensweise deutlich macht. Ob es der beste Weg ist weiß ich nicht, aber er hat sich bei mir auf jeden Fall bewährt. So hab ich z.B. auch die Möglichkeit, jedem Benutzer individuell alle möglichen Kombinationen von Rechten zu geben. |
AW: Benutzerrechte?
Delphi liefert da glaub ich wenig systematische Ansätze. Am ehesten sind vielleicht die schon erwähnten Actionlists oder auch die Form (als Maske) zu nennen.
Letztlich dreht sich alles um die Funktionen, die Deine Anwendung bereitstellt. Die Funktionen kannst Du beliebig mit Berechtigungsverfahren kreuzen. Funktion gegen Benutzergruppe oder -Level Funktion gegen Skill usw. usf. Dabei kann man ein Verfahren wählen wie hier bereits genannt, man kann sich an SQL orientieren (Select, Execute, Insert, Update, Delete) bis hin zu dem Recht, Rechte zu vergeben. Man kann diese Rechte auf Objekt oder bis hin zu Attributen oder Volumen ausdehnen, anhand einer Mandantendimension aufteilen und man kann auch Sichheits- oder Datenschutzaspekte berücksichtigen (was schon sehr professionell ist) Man kann in Berechtigungsverwaltung auch Object Lifecycles einbinden, womit das Recht zur Ausführung nicht mehr nur am Benutzerrecht hängt, sondern auch am Zustand des Objekts. Am Ende muss man noch berücksichtigen, dass all das auch zu verwalten ist (neben dem Coding) und man muss einen Mittelweg zwischen Aufwand und Nutzen finden. Wir haben mal ein solches System entwickelt und der Kunde hat irgendwann gefragt, ob man nicht die Mandantenebene weglassen kann und eine Rechtedefinition je Benutzer für alle Mandanten gilt. Es war ihm zuviel Aufwand. |
AW: Benutzerrechte?
Wichtig für das Handling ist es auf jeden Fall eine Trennung zwischen Personen und Rollen zu ermöglichen. Die Rollen sind Gruppen, denen Personen oder Gruppen angehören können und die Rechte von den Rollen mitbekommen.
Ziel muss es sein, dass die Berechtigungs-Struktur damit abgebildet werden kann. Da gibt es dann Abteilungsleiter, Sachbearbeiter, Chefs, Technische Leiter, ... die alle mehr oder weniger können dürfen oder sollen. Die einzelnen Personen können dann der ein oder anderen Rolle zugewiesen werden oder wieder entfernt werden. Trifft allerdings die Realität auf die Theorie, dann wird alles ganz schön blass. (siehe XP wo alle Administratoren sind). Ein so fein gestaltetes System mit Berechtigungen bis runter auf die einzelnen Objekte wird in den meisten Fällen eingestellt nach dem Weg des geringsten Widerstandes. |
AW: Benutzerrechte?
Hallo,
die Art und Weise wie man eine Benutzerrechteverwaltung (mit Delphi) realisiert ist die technische Seite. Leider wird dabei - wie viel zu oft auch in anderen Bereichen ersichtlich - von den Entwicklern die Praxistauglichkeit nur unzureichend berücksichtigt. Ich empfehle daher jedem Programmierer, das was er kocht auch selber zu essen. Sprich, die Benutzerrechteverwaltung auch auf seinem Entwickler-PC zu aktivieren. Spätestens wenn der Programmierer sich in zweistelliger Anzahl von Login's an seiner eigenen Software angemeldet hat, müsste das nachfolgend angesprochene Potential zur Optimierung bzw. Verbesserung ersichtlich werden. In meiner Benutzerverwaltung gibt es die Option (d.h. es ist Sache des Admin's das pro Benutzer zu aktivieren), einen Benutzer mit einem PC zu verknüpfen. Zusätzlich besteht bei dieser Option die Möglichkeit der automatischen Anmeldung. D.h. der Admin kann beispielsweise festlegen, wenn "Lieschen Müller" am PC "PC-Mueller" angemeldet ist, dann bekommt sie auch beim Start der SW automatisch die ihr zugewiesenen Rechte. Dieses Scenario ist besonders bei Arbeitsplätzen die nur von einer einzigen Person genutzt werden sehr weit verbreitet. In diesem Fall kann also der klassische Anmelde-Dialog entfallen, was in Folge mehrere positive Aspekte hat: - Benutzerfreundlichkeit: der aus Sicht des Anwenders "unsinnige" Anmeldedialog entfällt. - Der psychologische Effekt, dass der Benutzer gar nicht das Gefühl hat, seine Rechte sind eingeschränkt. - Akzeptanz: Benutzer empfinden die Benutzerverwaltung nicht als Gängelung oder Bevormundung. Zum sicherheitstechnischen Aspekt: Wenn der betreffende Benutzer in der Software eingeschränkte Benutzerrechte hat, spielt die automatische Anmeldung in der Praxis auch keinerlei sicherheitsrelevante Rolle. Mein Anmelde-Dialog ist dann zusätzlich in der Software integriert, d.h. erst wenn ein Admin administrative Arbeiten erledigen muss, meldet er sich beim Aufruf der "gesperrten" Funktion in der Software an. In dieser Situation kann dann in der Benutzerrechteverwaltung definiert werden, ob der Admin angemeldet bleibt, oder nach Aufruf der entsprechenden Funktion automatisch wieder abgemeldet werden soll. Mein Resümee aus jahrelanger praktischer Anwendung und Programmierung von Benutzerverwaltung ist daher: Die beste Benutzerverwaltung ist diejenige, die man nicht sieht. Infolge davon wird die Benutzerverwaltung sowohl von Anwendern als auch von Kunden/Administratoren nicht als notwendiges Übel, sondern vielmehr als praktikable Lösung einer sicherheitstechnischen Anforderung angesehen. Zur Speicherung: Ich persönlich bevorzuge die Speicherung einer Rechte-Struktur als Record in einem Binary-Blob-Field. Benutzername, PC-Name (siehe oben) und weitere Informationen in entsprechenden indizierten Feldern zur schnellen Lokalisierung bei der Anmeldung. |
AW: Benutzerrechte?
Zitat:
Wenn man oft auf der Benutzerseite steht, weiß man daß eben das nicht so oft der Fall ist. Gruß K-H |
AW: Benutzerrechte?
Man kann die Benutzerrechte-Verwaltung doch wie bei Windows gestalten: Zu jeden eingetragenen Benutzer läßt sich ein CheckBox-Feld (CheckListBox) anzeigen, so daß man sehr einfach alles anklicken kann, was der Benutzer darf und was nicht. Das rechnet man dann zu einem Integer oder Byte zusammen und kann locker eine Case-Abfrage implementieren, wenn sicherheitsrelevante Funktionen aufgerufen werden. Alternativ kann man auch die entsprechenden Menüeinträge gleich bei der Anmeldung sperren bzw. unsichtbar schalten. Bei kleinen Anwendergruppen benötigt man auch nur wenige Benutzerrechte, z.B.: Admin, Chef, Mitarbeiter, Gast, vielleicht noch SuperAdmin nur für den Programmierer.
Ich hab irgendwie den Eindruck, das Problem des TE besteht nicht darin, sich für ein bestimmtes Modell zu entscheiden, sondern wie er überhaupt so etwas programmieren könnte ... |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 20:42 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