Gibt es ein Delphi-Äquivalent zu den PermissionManager- oder AccessController-Klassen von Java?

9

Gibt es Klassen (frei, Open Source oder kommerziell), die eine ähnliche Zugriffskontrolle wie Java durchführen? AccessController tut? Ich möchte eine dynamische Gruppe von Richtlinien erstellen, die zur Laufzeit geändert werden können.

Aber ich möchte vermeiden, dass ich

programmieren muss %Vor%

überall. Ich weiß, dass ich wahrscheinlich meine Programmklassenhierarchie anpassen muss, aber ich bevorzuge das, anstatt Wachen überall manuell hinzuzufügen.

Wenn es keinen gebrauchsfertigen Code gibt, was wäre ein sinnvoller Ansatz? RTTI?

Bearbeiten: Hier ist ein Beispiel aus der Sicherheitsanmerkungen und Autorisierung in GlassFish und der Java EE 5 SDK Artikel. Da jemand Anmerkungen in einem Kommentar erwähnt hat, denke ich, dass dies ideal wäre:

%Vor%

Aus dem Artikel:

  

In diesem Beispiel ist die Methode hello () für alle zugänglich, und die Methode bye () ist für Benutzer der Rolle javaee zugänglich.

Bearbeiten: Nun, es scheint, dass der allgemeine Konsens ist, dass dies in Delphi nicht möglich ist. Andere denken, dass es ein schlechter Ansatz ist.

Ich denke immer noch, das wäre großartig. Meine Erfahrung mit Annotationen in Java (als Code-Affe weit unten im Totempfahl) ist positiv. Sie fügen eine neue Methode hinzu, fügen eine Art von Annotation hinzu (nicht genau das Gleiche wie Java Security Annotations) und Sie sind fertig. Ein Administrator kann später zum Admin-Steuerfeld wechseln und einer neuen Gruppe oder einzelnen Benutzern einen Gewährungszugriff für diesen neuen Handler hinzufügen. Es funktioniert einfach.

Dies sind meine aktuellen Alternativen:

  1. Das TMS-Sicherheitssystem - dies erscheint wie eine Komplettlösung mit mehreren Tools. Sehenswert. Ich akzeptiere dies als eine Antwort, auch wenn ich wahrscheinlich nicht dafür bin.
  2. Das ist etwas, was vielversprechend aussieht: Delphi virtuelles Methodenabfangen . Es funktioniert nur mit virtuellen Methoden, aber ich glaube nicht, dass das zu schwierig ist. Dies und Anmerkungen könnten ein interessantes System ergeben (es scheint, dass dies ursprünglich für die DataSnap-Authentifizierung entworfen wurde)
  3. Sie haben nur einen ActionManager in Ihrer Anwendung und stellen sicher, dass alle Aktionen nur von dort aus gestartet werden können. Auf diese Weise können Sie den Action Manager OnExecute method; Ich gebe vor, die Eigenschaft TAction.Name als Berechtigungsnamen ("handler") zu verwenden und eine Liste zulässiger Aktionen aus einer Tabelle zu lesen. Ich kann die Aktionsliste aus dem Aktionsmanager verwenden, um die gesamte Liste in der Admin-Benutzeroberfläche anzuzeigen.
Leonardo Herrera 13.02.2012, 23:08
quelle

2 Antworten

1

Ja, es gibt eine Delphi Zugriffskontrollbibliothek (lkacl) (OpenSource), JCL (OpenSource) bietet eine ziemlich umfassende Sicherheit Funktionen , und schließlich, wenn Ihre Anforderungen wirklich hoch wären, ist die beliebteste kommerzielle Lösung TMS Security System .

    
user1080697 20.02.2012, 03:37
quelle
2

Es gibt noch keinen solchen Rahmen für Delphi, noch ein Konzept wie EJBs, das dazu passen würde. DELPHI unterstützt Klassenannotationen, und ein Framework wie dieses könnte vielleicht in Verbindung mit TAction entworfen werden, um Sicherheit auf einer Aktionsebene zu bieten, aber ich bezweifle, dass dies auf das Blockieren bestimmter Methodenaufrufe ausgedehnt werden könnte. Delphi-Code fragt nicht immer die Berechtigung zum Aufrufen einer virtuellen Methode. Alles, was sich in JEDEN virtuellen Methodenaufruf in Delphi eingefügt hat, würde das Hinzufügen eines checkPermission Call hinter den Kulissen (meiner Meinung nach) böse sein. Es wäre langsam und schlimmer, als solche Schecks per Hand zu schreiben.

Allerdings könnten die gleichen Techniken, die für Mock-Delphi-Klassen verwendet werden, vielleicht verwendet werden, um in Zukunft ein automatisches Sicherheits-Wrapper-Objekt zu erstellen.

Ich vermute, dass, wenn die betreffende Java-Bibliothek Aspects verwendet (im Wesentlichen "Injektion" über eine Technik wie Code-Hooking implementiert), dann würde es keine "CheckAllowed" -Aufrufe überall benötigen. Wenn es Ihnen nichts ausmacht, alle Methodenaufrufe auf die Implementierung einer Schnittstelle zu ändern und dann einen Wrapper bereitzustellen, der die Methodenaufrufe ausführt und eine Art automatisch generierten Mock-Security-Wrapper verwendet, können Sie Aufrufe von CheckAllowed vermeiden.

Also ein bewachtes Nein, mit einer "begrenzten Rahmen möglich in Zukunft" -Klausel.

    
Warren P 20.02.2012 14:09
quelle

Tags und Links