Guten Abend,

"Warnung: - unstrukturiertes Problem - "

In einem Programm zur Auftragsbearbeitung komme ich jetzt an das Problem verschiedener
Nutzerrechte. Ganz konkret, wer darf Artikel im Artikelkatalog löschen, wer darf Rechnungen
drucken und wer Lieferscheine.... Oft ist es auch so, dass eine Nutzergruppe nur an einem jeweiligen Rechner arbeitet. Bin mir allerdings über die prinzipielle herangehensweise nicht einig.


Im Prinzip hängt von der Nutzergruppe ab, ob alle oder nur eine Auswahl von Buttons mit Funktionen verfügbar ist. MAn könnte ein Programm je nach Nutzergruppe mit einem Parameter starten und die Buttons in Abhängigkeit davon als enabled/disabled stellen. Dann würden meine Buttons Parametereigenschaften bekommen. Oder brauch man dazu ein Nutzerobjekt mit Login wovon wieder
die Buttonverfügbarkeit abhängt. Gibt es in Delphi schon Modelle oder hat jemand hier schon praktische Erfahrungen und eine Vorgehensweise für sich entwickelt?

Grüße // Martin

Zitat von mschaefer:

Guten Abend,

"Warnung: - unstrukturiertes Problem - "

In einem Programm zur Auftragsbearbeitung komme ich jetzt an das Problem verschiedener
Nutzerrechte. Ganz konkret, wer darf Artikel im Artikelkatalog löschen, wer darf Rechnungen
drucken und wer Lieferscheine.... Oft ist es auch so, dass eine Nutzergruppe nur an einem jeweiligen Rechner arbeitet. Bin mir allerdings über die prinzipielle herangehensweise nicht einig.


Im Prinzip hängt von der Nutzergruppe ab, ob alle oder nur eine Auswahl von Buttons mit Funktionen verfügbar ist. MAn könnte ein Programm je nach Nutzergruppe mit einem Parameter starten und die Buttons in Abhängigkeit davon als enabled/disabled stellen. Dann würden meine Buttons Parametereigenschaften bekommen. Oder brauch man dazu ein Nutzerobjekt mit Login wovon wieder
die Buttonverfügbarkeit abhängt. Gibt es in Delphi schon Modelle oder hat jemand hier schon praktische Erfahrungen und eine Vorgehensweise für sich entwickelt?

Grüße // Martin

Hallo Martin,

da steht Dir ja einiges bevor. Du brauchst für due spätere effiziente Verwaltung mindestens einen Abkömmling von TActionlist. Diese füllt die Verfügbarkeit bestimmter Actions beim Wechsel des Benutzers. Wenn Du dann alles (Menüs, Buttons etc.) über diese Actionlist-Kompos laufen lässt, erledigt Delphi viel von dem Kleinkram (z.B. Elemente disablen) für Dich. Die Berechtigungen und Actions würde ich in einer verschlüsselten DB-Tabelle eintragen. Vielleicht als Key dort den Tag (des Objects) verwenden.
Schlimmer wird es nur, wenn dir Berechtigungen auch noch in Ansehen/Lesen/Schreiben/Neuanlegen/Löschen bis auf Feldebene gehen sollen. Dann würde ich Dir eine fertige Komponentensammlung dafür empfehlen.

Hallo Union,

schon mal vielen Dank für Deine Antwort. Das werde ich sicher nicht mal eben angehen. Etwas Zeit zum Vordenken braucht das wohl. Um eine einge Lösung (wegen mir auch Komponenten) werde ich nicht umhin kommen, da ich ehedem mit einer eigenen Komponentesammlung arbeite.

Die Idee sich da über eine Ableitung von TActionList zu beschäftigen klingt gut.
Das Problem mit den Dateiaktionen bekommt man über eine abgeleitete DBNavigatrokomponente in den Griff. Da gibt es auch NavigatorButtons und damit bin ich wieder auf Buttonebene.

Viele Grüße // Martin

Hi!

Zitat von mschaefer:

MAn könnte ein Programm je nach Nutzergruppe mit einem Parameter starten und die Buttons in Abhängigkeit davon als enabled/disabled stellen.

Dabei würde ich aber bedenken, dass sich jemand ganz schnell Zugang zu Sachen verschaffen kann, die ihn nix angehen.
Er müsste ja nur den Parameter ändern.


Ciao Frederic

Hallo Martin,

wo sind denn eigentlich die Daten gespeichert. Ich mein, in welcher Datenbank, wenn es denn überhaupt eine Datenbank ist.

Falls du einen richtigen Datenbank Server dein Eigen nennst (z.B. MSSQL, Oracle, Firebird etc.), dann bietet es sich eigentlich an, die Daten gleich auf Serverebene für die einzelnen Benutzergruppen zu sperren. Buttons disablen/enabled ist schön und gut und als Ergänzung sehr sinnvoll, aber z.B. das eigentliche Verbieten von Ändern der Daten für einige Benutzer sollte dann schon auf Datenbankebene erledigt werden, sonst hast du nämlich prinzipiell null Schutz gegen Einblick von aussen.

Gruß,
Tom

Hallo Frederic, hallo Tom, hi Union

Das System läuft auf Firebird, wobei es bisher keine Nutzergruppen gibt. Das Problem fing damit an, das jetzt Rechner auch im Kundenbereich stehen, wo er nicht immer unter Aufsicht steht. Im Moment läuft eine Screensaverlösung. Man schaltet den per Passowrt frei; also eher etwas "spartansich".

Letzlich muß es drei Nutzergruppen geben: User mit allen Rechten, Kandidaten nur ohne Löschrechte und eine Gruppe mit lediglich Sichtungsrechten. Da hängen natürlich auch Funktionen dran, dass nur aus dem Büro heraus Rechnungen gedruckt werden sollen.


1.Ergebnis:
Herausgelesen habe ich von Euch, das man die Anwender am besten ebenfallse in der
Datenbank ablegt. Das ist im Prinzip auch schon vorhanden, aber bisher ohne Funktion
im Programm, da ich mir wie gesagt bisher über die Logic nicht richtig im Klaren bin.

2.Ergebnis:
Die Variante " Funktionsbuttons -> User-ActionList " versuche ich derzeit durchzuspielen.
Die Variante Parametersteuerung ist gecancelled.

Grüße // Martin

Zitat von mschaefer:

Das Problem fing damit an, das jetzt Rechner auch im Kundenbereich stehen, wo er nicht immer unter Aufsicht steht.

In dem Fall würde ich UNBEDINGT die Serversicherheit von Firebird nutzen, da du auf entfernten Rechnern überhaupt keinen Einblick hast, wer da was drauf macht. Wer sich bischen mit Computern auskennt kommt schnell auf die Idee, z.B. mit IBConsole o.ä. zu versuchen, sich in die Datenbank einzuloggen, und kann da weil ja noch Adminrechte bestehen, so ziemlich alles kaputt machen. Es wäre fahrlässig, dies nicht zu unterbinden.

Gerade bei Firebird kannst du sehr schön Lese-Edit-Insert-Lösch-Rechte jeder einzelnen Benutzergruppe vergeben. In diese Gruppen nimmst du dann deine Logins auf. Ist in etwa mit der Windows Benutzeraccount Logik zu vergleichen. Adminrechte kriegt KEINER, ausser du (und dein Chef ). Jedenfalls nicht Ottonormaluser bei den Kunden. Das wär viel zu gefährlich.

Wenn das jetzt erst einmal steht, ist die Sicherheit schon mal gegeben, ohne auch nur eine Zeile Code im Delphi zu ändern. Wenn einer ohne entsprechende Rechte versucht, einen Datensatz zu löschen, kriegt er schlicht und einfach eine Fehlermeldung. Ist zwar nicht schön, aber schon mal sehr funktionell, und eben vor allem sicher. Das mit dem Disablen von Buttons ist, wie bereist oben gesagt, schön für die Programmbedienung, aber zwingend notwendig ist das nicht.

Ein Problem will ich noch ansprechen, auf das du früher oder später stößt. Stell dir eine Gruppe vor, die neue Rechnungen einsehen darf, erstellen darf, ändern darf, jedoch NICHT drucken darf. Auf Tabellenebene allein kannst du das nicht einstellen, da du lesen können musst. Und wenn du lesen kannst, somit kannst du prinzipiell auch Rechnungen drucken. Ein Ausweg ist das Erstellen einer View, welches eine 1:1 Kopie deiner Rechnungstabelle darstellt. Lesezugriff auf diese View gibts du nur den Gruppen, die auch drucken dürfen. Das Drucken an sich erfolgt dann auf Basis dieser View, und nicht direkt auf Basis deiner Tabelle. Somit hast du dieses Sicherheitsloch auch gestopft. Alles Andere ist nur noch bischen Kosmetik in deinem Programm, dürfte aber prinzipiell kein Problem darstellen.

Gruß,
Tom

PS: Immer weiter munter fragen, denn mit solchen Porblemen hatte ich in Vergangenheit schon des öfteren zu tun.

N´abend Tom,

die nächsten Tage werde ich mich erstmal auf die Programmlogik konzentrieren. Du hast mit dem Absichern recht, das wird sukzessive geändert (zuwenig Zeit für zuviel Aufgabe -> wie üblich). Im Moment überlege ich für die drei Nutzergruppen jeweils eine Action-List zur Verfügung zu stellen. Dann brauchte ich eine Nutzerkomponente, die in jedem Button angegeben wird. Diese liefert dem
Button dann die zugehörige Actionlist, in Abhängikeit wer gerade angelogged ist. (Betadenkphase)

Grüße // Martin