<\/p>\n
Im Beitrag „Berechtigungen für Access-Objekte per SQL Server I: Tabellen“ haben wir ein Datenmodell entwickelt für die Verwaltung der Berechtigungen verschiedener Benutzergruppen auf die Formulare, Berichte und Steuer-elemente einer Access-Anwendung – gesteuert über die jeweilige Anmeldung an der SQL Server-Datenbank. Im zweiten Teil dieser Beitragsreihe haben wir das Formular zum Einstellen der Berechtigungen erstellt. Im dritten Teil zeigen wir nun, wie wir die gespeicherten Berechtigungen nutzen, um Formulare und Steuer-elemente vor dem unbefugten Zugriff zu schützen.<\/b><\/p>\nBerechtigungen anwenden<\/h2>\n
Damit ist der erste Teil abgeschlossen – wir haben eine Möglichkeit geschaffen, mit der wir die Formulare einer Anwendung und die enthaltenen Steuer-elemente einlesen können. Außerdem können wir die Benutzergruppen, die am SQL Server in Form von Anmeldungen vorliegen, ermitteln und für die Kombination aus Elementen und Benutzergruppen eine der drei Berechtigungsstufen Keine<\/b>, Lesen <\/b>oder Alle <\/b>einstellen. Nun ändert dies allein noch nichts im Umgang mit den Elementen der Benutzeroberfläche, denn noch wissen diese ja nichts davon, dass der Zugriff auf die jeweiligen Formulare oder Steuer-elemente gegebenenfalls eingeschränkt ist. Die Interpretation der drei Berechtigungsstufen sieht für Formulare wie folgt aus:<\/p>\n Für die Steuer-elemente sollen die drei so auswirken:<\/p>\n Um ein Formular und seine Steuer-elemente mit den entsprechenden Werten für die betroffenen Eigenschaften zu versehen, benötigen wir noch ein wenig Code. Die Hauptfunktion dabei heißt BerechtigungenAnwenden <\/b>und erwartet einen Verweis auf das zu öffnende Formular als Parameter. Diese Prozedur erläutern wir weiter unten. Bevor Sie diese Prozedur nutzen können, sind nämlich noch einige Vorbereitungen nötig – siehe weiter unten.<\/p>\n Die Prozedur verwendet die Funktion SPRecordsetMitParameter<\/b> (siehe weiter unten), um eine gespeicherte Prozedur in der SQL Server-Datenbank auszuführen und ein darauf basierendes Recordset zu erstellen. Diese gespeicherte Prozedur müssen wir zunächst anlegen, und zwar wahlweise im SQL Server Management Studio oder im Formular frm-SQL-Befehle<\/b>, das wir im Beitrag SQL Server Tools <\/b>vorgestellt haben (www.access-im-unternehmen.de\/1061<\/b>).<\/p>\n Anschließend steht diese gespeicherte Prozedur für die Verwendung in der Datenbank Suedsturm_SQL <\/b>zur Verfügung. Sie können diese ausprobieren, werden aber gegebenenfalls keinen Datensatz als Ergebnis erhalten. Wenn Sie die im zweiten Teil dieser Beitragsreihe erstellten Beispielberechtigungen für das Formular frmIntro<\/b> für die beiden Gruppen Bestellannahme <\/b>und Management <\/b>testen wollen, sollten Sie sich bewusst sein, unter welchem Benutzerkonto Sie gerade am Windows-Rechner angemeldet sind und ob dieses Benutzerkonto einer dieser beiden Gruppen zugehört. Falls ja, werden Sie einen entsprechenden Datensatz erhalten, den wir uns gleich ansehen werden. Falls nicht, müssen wir zunächst die Voraussetzungen schaffen, damit Sie sich unter einer der beiden Benutzergruppen an der SQL Server-Datenbank anmelden. Dazu gibt es wiederum zwei Möglichkeiten:<\/p>\n Wir wollen testweise, sofern noch nicht vorhanden, die Benutzergruppe Management <\/b>mit dem Benutzer Peter Gross <\/b>und die Benutzergruppe Bestellannahme <\/b>mit dem Benutzer Harry Klein <\/b>anlegen. Das erledigen Sie über die Eingabeaufforderung ganz schnell mit den folgenden Anweisungen. Die Benutzerkonten fügen Sie so hinzu:<\/p>\n Die Gruppen legen Sie so an:<\/p>\n Schließlich fügen Sie die Benutzer noch den Gruppen hinzu:<\/p>\n Dass die Gruppen und Benutzer angelegt wurden, können Sie auch prüfen. Geben Sie den folgenden Befehl ein, um alle Benutzer auszugeben:<\/p>\n Mit dem nächsten Befehl geben Sie alle Benutzergruppen aus:<\/p>\n Wenn Sie die Details einer Gruppe inklusive Benutzer ermitteln wollen, gelingt dies durch Angabe des Gruppennamens:<\/p>\n Und auch über die Benutzerdetails können Sie die Gruppenzugehörigkeit ermitteln:<\/p>\n Damit haben Sie die passenden Benutzerkonten und Benutzergruppen für die folgenden Experimente erstellt.<\/p>\n Außerdem müssen wir die Benutzergruppen noch als neue Anmeldung zum SQL Server hinzufügen. Das erledigen wir im SQL Server Management Studio, indem wir mit der rechten Maustaste auf das Element >Servername<|Si-cher-heit|An-meldungen <\/b>klicken und den Kontextmenü-Eintrag Neue Anmeldung <\/b>betätigen.<\/p>\n Es erscheint der Dialog Anmeldung – Neu<\/b>. Hier klicken Sie neben dem Feld Anmeldename <\/b>auf die Schaltfläche Suchen<\/b>. Im nächsten Dialog Benutzer oder Gruppe auswählen <\/b>klicken Sie zunächst auf Objekttypen<\/b>. Im Dialog Objekttypen aktivieren <\/b>Sie, sofern noch nicht geschehen, den Eintrag Gruppen <\/b>und schließen den Dialog wieder.<\/p>\n Dann klicken Sie im Dialog Benutzer oder Gruppe auswählen <\/b>auf die Schaltfläche Erweitert<\/b>. Im neuen Dialog gleichen Namens klicken Sie rechts auf die Schaltfläche Jetzt suchen <\/b>und wählen dann unten aus den Suchergebnissen die Gruppe Bestellannahme <\/b>aus. Schließen Sie den Dialog mit OK <\/b>und den aufrufenden Dialog ebenfalls, nachdem Sie sich vergewissert haben, dass unter Geben Sie die zu verwendenden Objektnamen ein <\/b>die gewünschte Gruppe aufgeführt wird.<\/p>\n Zurück im Dialog Anmeldung – Neu <\/b>wechseln Sie noch zum Bereich Benutzerzuordnung und aktivieren dort die Datenbank Sued-sturm_SQL<\/b>. Dann erstellen Sie Anmeldung mit einem Klick auf OK<\/b>.<\/p>\n Auf die gleiche Weise verfahren Sie anschließend mit der Benutzergruppe Management<\/b>. Sie können auch direkt im ersten Dialog Anmeldung – Neu <\/b>die Benutzergruppe in der Form >Servername<\\<Gruppenname> <\/b>eingeben.<\/p>\n Danach sollten Sie im Bereich Sicherheit|Anmeldungen <\/b>die beiden neuen Anmeldungen mit den Benutzergruppen vorfinden (siehe Bild 1).<\/p>\n Bild 1: Einrichten der Benutzergruppen als SQL Server-Anmeldungen<\/span><\/b><\/p>\n Bevor wir uns gleich im Kontext eines der beiden Benutzer Peter Gross oder Harry Klein am SQL Server anmelden, erstellen wir noch die gespeicherte Prozedur, die wir dort ausprobieren wollen. Den dazu notwendigen Code finden Sie in Listing 1 (die Erläuterung folgt weiter unten).<\/p>\n Listing 1: Gespeicherte Prozedur, welche die Berechtigungen für den aktuellen Benutzer für das übergebene Formular ermittelt.<\/span><\/b><\/p>\n Um die gespeicherte Prozedur anzulegen, führen Sie den CREATE PROCEDURE<\/b>-Code in einem Abfragefenster der Datenbank Suedsturm_SQL <\/b>aus. Nach der Aktualisierung des Elements <Servername>|Da-ten-ban-ken|Sued-sturm_SQL|Pro-gram-mier-bar-keit|Ge-spei-cher-te Prozeduren <\/b>sollte darunter ein neuer Eintrag namens spObjektberechtigungen <\/b>auftauchen. <\/p>\n Damit die neuen Benutzergruppen nun auch noch die gespeicherte Prozedur spObjektberechtigungen <\/b>nutzen können, müssen wir diesen noch die passenden Berechtigungen geben. Dazu klicken Sie mit der rechten Maustaste auf den Eintrag für diese gespeicherte Prozedur im Objekt-Explorer und wählen aus dem Kontextmenü den Eintrag Eigenschaften <\/b>aus. Wechseln Sie hier zum Bereich Berechtigungen<\/b>, markieren Sie nacheinander die beiden betroffenen Gruppen Management <\/b>und Bestellannahme <\/b>und aktivieren Sie die Option Erteilen <\/b>für die Berechtigung Ausführen <\/b>(siehe Bild 2).<\/p>\n Bild 2: Erteilen der Berechtigungen für die gespeicherte Prozedur<\/span><\/b><\/p>\n Diese Prozedur sieht etwas kompliziert aus, aber wir lösen das jetzt auf. Der größte Teil der SELECT<\/b>-Anweisung ist das Konstrukt zum Herstellen der Verknüpfungen der vier beteiligten Tabellen tblObjekteBenutzergruppenBerechtigungen<\/b>, tblBerechtigungsstufen<\/b>, tblObjekte <\/b>und tblBenutzergruppen <\/b>per INNER JOIN<\/b> – das ist der Teil von FROM <\/b>bis WHERE<\/b> im unteren Bereich. Dies würde grundsätzlich alle Datensätze liefern, die in den vier Tabellen angelegt wurden. Da wir nur bestimmte Berechtigungen benötigen, in diesem Fall für ein spezielles Objekt, dass wir mit dem Parameter @Objekt <\/b>übergeben, haben wir dafür eine Bedingung in der WHERE<\/b>-Klausel festgelegt und noch ein weiteres. Die folgende Bedingung sorgt also dafür, dass wir nur die Berechtigungen für die Elemente erhalten, deren übergeordnetes Objekt das mit @Objekt <\/b>übergebene Formular ist (t6 <\/b>ist ein Alias für die Tabelle tblObjekte<\/b>):<\/p>\n Außerdem möchten wir nur solche Datensätze für die aktuelle Benutzergruppe zurückliefern. Dabei unterstützt uns die T-SQL-Funktion IS_MEMBER<\/b>. Sie erwartet den Namen einer Anmeldung, in diesem Fall etwa die Gruppe <Servername>\\Management<\/b>, und prüft, ob der Benutzer, der gerade am Windows-Rechner angemeldet ist, zu dieser Gruppe gehört. t7 <\/b>ist dabei ein Alias für die Tabelle tblBenutzergruppen <\/b>und Bezeichnung der Name der Benutzergruppe:<\/p>\n Welche Werte soll die gespeicherte Prozedur nun zurückliefern Die ersten beiden Werte sind keine einfachen Werte, die aus der per INNER JOIN <\/b>verknüpften Kombination der vier Tabellen stammen, sondern die Ergebnisse von Unterabfragen. Hier ist die erste Unterabfrage:<\/p>\n Diese Abfrage bestimmt die Anzahl der Datensätze der beiden per INNER JOIN <\/b>verknüpften Tabellen tblObjekteBenutzergruppenBerechtigungen <\/b>und tblBenutzergruppen<\/b>, wobei hier nur die Datensätze berücksichtigt werden sollen, deren ObjektID <\/b>der Tabelle tblObjekteBenutzergruppenBerechtigungen <\/b>auch in der gleichnamigen Tabelle der Hauptabfrage vorkommen. Da wir zweimal die gleiche Tabelle referenzieren, haben wir diesen jeweils einen Alias (hier t1 <\/b>und t4<\/b>) vergeben und dies auch direkt für alle referenzierten Tabellen der Haupt- und der beiden Unterabfragen erledigt. Das Ergebnis dieser Unterabfrage, das in Form des Feldes AnzahlFestgelegterBerechtigungen <\/b>in der Hauptabfrage landet, entspricht der Anzahl der expliziten Berechtigungen an diesem Objekt für den aktuellen Benutzer. Wenn der Benutzer etwa in einer Benutzergruppe ist, die eine Lesen-Berechtigung für ein Formular hat, liefert AnzahlFestgelegterBedingungen <\/b>den Wert 1 <\/b>zurück. Ist der Benutzer in zwei Gruppen, von denen die eine Lesen-Rechte und die andere das Recht Keine <\/b>hat, liefert AnzahlFestgelegterBedingungen <\/b>den Wert 2<\/b>. Ist der Benutzer aber in einer Gruppe, die Lesen-Rechte hat und in einer anderen Gruppe, für die keine expliziten Rechte für das Formular festgelegt sind, dann liefert AnzahlFestgelegterBedingungen <\/b>den Wert 1<\/b>. Wozu das dient, wird gleich deutlich.<\/p>\n <\/p>\n Zunächst schauen wir uns noch die zweite Unterabfrage an. Diese lautet wie folgt:<\/p>\n Diese Unterabfrage gibt einfach nur die Anzahl der Gruppen des Benutzers zurück. Sie zählt alle Einträge der Tabelle tblBenutzergruppen<\/b>, für welche die Funktion IS_MEMBER <\/b>den Wert 1 <\/b>zurückgibt.<\/p>\n Der Sinn der beiden Unterfunktionen ist folgender: Wenn die Anzahl von AnzahlFestgelegterBerechtigungen <\/b>und AnzahlGruppenDesBenutzers <\/b>gleich groß sind, können wir schlussfolgern, dass für jede der Benutzergruppen des Benutzers eine explizite Berechtigung an dem jeweiligen Element festgelegt wurde. Wenn AnzahlFestgelegterBerechtigungen <\/b>kleiner ist als AnzahlGruppenDesBenutzers<\/b>, dann gibt es Benutzergruppen für den Benutzer, für die keine explizite Berechtigung an dem mit @Objekt <\/b>übergebenen Objekt festgelegt ist. Und da wir definiert haben, dass keine explizite Berechtigung bedeutet, dass der Benutzer das Schreiben-Recht an dem Objekt erhält, wird in diesem Fall auch das Schreiben-Recht festgelegt, egal welche Rechte die anderen Benutzergruppen für den Zugriff auf dieses Objekt besitzen.<\/p>\n Neben diesen beiden Feldern, die aus Unterabfragen generiert werden, soll die gespeicherte Prozedur noch die Felder ObjektID <\/b>der Tabelle tblObjekteBenutzergruppenBerechtigungen<\/b>, Bezeichnung <\/b>der Tabelle tblObjekte <\/b>und den größten Wert des Feldes BerechtigungsstufeID <\/b>der Tabelle tblObjekteBenutzergruppenBerechtigungen <\/b>liefern.<\/p>\n Jetzt wird es interessant – wir wollen die gespeicherte Prozedur zunächst testweise im SQL Server Management Studio ausprobieren, und zwar im Kontext verschiedener Benutzer. Uns interessiert vor allem, ob es funktioniert, die nicht expliziten Berechtigungen für Gruppen zu ermitteln.<\/p>\n Um das SQL Server Management Studio im Kontext eines anderen Benutzers zu öffnen, klicken Sie mit der rechten Maustaste auf das Programm SQL Server Management Studio<\/b>. Dort finden Sie dann wiederum den Eintrag Microsoft SQL Server Management Studio<\/b>, auf den Sie nochmals mit der rechten Maustaste klicken – diesmal allerdings bei gedrückter Umschalttaste. Dies liefert einige Kontextmenü-Einträge mehr als üblich, unter anderem Als anderer Benutzer ausführen<\/b>. Es erscheint dann ein Dialog, in dem Sie den Benutzernamen und das Kennwort des gewünschten Benutzers eingeben (siehe Bild 3).<\/p>\n Bild 3: Anwendung als anderer Benutzer öffnen<\/span><\/b><\/p>\n Zuerst melden wir uns als Peter Gross <\/b>an, der nur der Gruppe Manager <\/b>angehört. Für diese haben wir im Formular frmBerechtigungen <\/b>das Recht Alle<\/b> für das Formular frmIntro <\/b>und das Steuer-element cmdGo <\/b>festgelegt.<\/p>\n Wir suchen nun den Eintrag <Servername>|Da-ten-ban-ken|Sued-sturm_SQL|Pro-gram-mier-bar-keit|Ge-speicher-te Prozeduren <\/b>heraus und finden darunter auch unsere Prozedur spObjektberechtigungen <\/b>vor. Klicken Sie mit der rechten Maustaste darauf und wählen Sie den Eintrag Gespeicherte Prozedur ausführen… <\/b>aus. Im nun erscheinenden Dialog (siehe Bild 4) geben wir als Parameter frmIntro <\/b>ein.<\/p>\n Bild 4: Gespeicherte Prozedur ausführen<\/span><\/b><\/p>\n Das Ergebnis sieht wie in Bild 5 aus. Es gibt je einen Datensatz für das Formular-Element des Formulars (Bezeichnung: Form<\/b>) und einen für das einzige Steuer-element cmdGo<\/b>, für das wir Rechte vergeben haben. Der Benutzer gehört zu einer Gruppe und es gibt eine festgelegte Berechtigung für jedes Element. Das ist ein klarer Fall – es gibt keine Gruppe, für die keine explizite Berechtigung definiert wurde, also gilt der Wert aus MaxBerechtigungID <\/b>als maßgeblicher Wert für das Durchsetzen der Berechtigungen. In diesem Fall bedeutet dies, dass der Benutzer der Gruppe Management <\/b>mit dem Wert 3 <\/b>das Recht Alle <\/b>für das Formular und die Schaltfläche hat.<\/p>\n Bild 5: Ergebnis der gespeicherten Prozedur für einen Benutzer mit einer Gruppe<\/span><\/b><\/p>\n Danach melden wir uns mit dem Benutzer Harry Klein <\/b>aus der Bestellannahme an, für den wir für das Formular lesende Rechte angelegt haben und für die Schaltfläche cmdGo <\/b>kein explizites Recht. Nun erhalten wir das Ergebnis aus Bild 6. Dort finden wir nun nur einen Datensatz vor, und zwar für das Formular selbst – nicht für die Schaltfläche. Was bedeutet das für uns Erstmal nicht viel – die Interpretation dieser Daten erfolgt ja weiter unten in einer VBA-Prozedur, die beim öffnen des Formulars aufgerufen wird. Um vorwegzugreifen: Formulare und Steuer-elemente sind standardmäßig mit vollen Zugriffsrechten ausgestattet, also kann der Benutzer, wenn er einer Gruppe angehört, die gar keine expliziten Berechtigungen aufweist, alle Formulare öffnen und für den schreibenden Zugriff nutzen und auch alle Steuer-elemente verwenden.<\/p>\n Bild 6: Ergebnis der gespeicherten Prozedur für einen Benutzer mit einer Gruppe und nur einer expliziten Berechtigung<\/span><\/b><\/p>\n Wir haben noch einen dritten Benutzer namens Horst Müller <\/b>angelegt, der den beiden Gruppen Management <\/b>und Bestellannahme <\/b>angehört. Wenn wir das SQL Server Management Studio im Kontext dieses Benutzers öffnen und die gespeicherte Prozedur spObjektberechtigungen <\/b>für das Formular frmIntro <\/b>ausführen, erhalten wir das Ergebnis aus Bild 7. Hier erkennen wir in der ersten Zeile für die Schaltfläche cmdGo<\/b>, dass unter AnzahlFestgelegterBerechtigungen <\/b>der Wert 1 <\/b>steht, aber unter AnzahlGruppenDesBenutzers <\/b>der Wert 2<\/b>. Dies wird später in der Auswertung in der VBA-Prozedur dazu führen, dass wir erkennen, dass für eine Gruppenzugehörigkeit keine explizite Berechtigung für das Objekt festgelegt wurde – was bedeutet, dass wir hierfür das Recht Alle <\/b>festlegen.<\/p>\n Bild 7: Ergebnis der gespeicherten Prozedur für einen Benutzer mit zwei Gruppen, wo nur bei einer Gruppe ein explizites Recht für den Zugriff auf die Schaltfläche cmdGo festgelegt ist<\/span><\/b><\/p>\n Damit kommen wir endlich zur VBA-Funktion BerechtigungenAnwenden<\/b>. Sie erwartet einen Verweis auf das zu untersuchende Formular als Parameter und liefert einen Boolean-Wert zurück (siehe Listing 2).<\/p>\n Listing 2: Funktion zum Ermitteln der Berechtigungen für ein Formular<\/span><\/b><\/p>\n Die Prozedur nutzt die bereits weiter oben erwähnte Funktion SPRecordsetMitParameter<\/b>, um ein Recordset auf Basis der gespeicherten Prozedur spObjektberechtigungen <\/b>zu erstellen unter Verwendung der Verbindungszeichenfolge, welche die Funktion Standardverbindungszeichenfolge <\/b>liefert (diese bezieht ihre Daten aus der Tabelle tblVerbindungszeichenfolgen<\/b>, die Sie wiederum über das Formular frmVerbindungszeichenfolgen <\/b>mit den Daten Ihres SQL Servers füllen können). Als dritten Parameter übergeben wir den Namen des Formulars. Dies ist der Parameter, den auch die gespeicherte Prozedur nutze.<\/p>\n Bevor wir in eine Do While<\/b>-Schleife einsteigen, mit der wir die Datensätze des Recordsets durchlaufen, stellen wir noch den Wert der Variablen bolForm <\/b>auf True <\/b>ein. Diese Variable wird gleich gegebenenfalls verändert und dann als Funktionswert an die aufrufende Prozedur zurückgegeben werden. Sie legt fest, ob das Formular geöffnet werden darf oder nicht. Da wir die Variable zu Beginn auf True <\/b>einstellen, gehen wir vor Einsicht der einzelnen Berechtigungen davon aus, dass jedes Formular zunächst einmal geöffnet werden darf.<\/p>\n Danach startet die Schleife, in der wir alle Datensätze des Ergebnisses der gespeicherten Prozedur spObjektberechtigungen <\/b>durchlaufen. Hier prüfen wir nun die Werte der beiden Felder AnzahlGruppenDesBenutzers <\/b>und AnzahlFestgelegterBerechtigungen<\/b>. Es kann ja geschehen, dass der Benutzer mehr Gruppen angehört als Berechtigungen für seine Gruppen festgelegt sind. In diesem Fall haben wir eine Gruppe ohne explizit festgelegte Berechtigung für das aktuelle Element, was bedeutet, dass wir davon ausgehen, dass die Gruppe die vollen Berechtigungen erhält. Dann stellen wir den Wert der Variablen lngMaxBerechtigungID <\/b>auf 3 <\/b>ein. Anderenfalls, also wenn die Anzahl der Gruppen und der festgelegten Berechtigungen gleich ist, erhält diese Variable den Wert aus dem Feld MaxberechtigungID<\/b>.<\/p>\n Danach prüfen wir in einer Select Case<\/b>-Bedingung, für welche Art von Element wir die Berechtigungen untersuchen. Es gibt nur zwei Möglichkeiten – für das Formular selbst (Form<\/b>) oder für eines der enthaltenen Steuer-elemente. Im Falle des Formulars stellen wir den Wert von bolForm<\/b>, also des späteren Rückgabewertes, auf True <\/b>ein, wenn lngMaxBerechtigungen <\/b>einen Wert größer als 1 <\/b>enthält (also Lesen <\/b>oder Alle<\/b>). Dieser Rückgabewert entscheidet übrigens nur darüber, ob das Formular überhaupt geöffnet werden darf und nicht, ob der Benutzer dann lesende oder alle Rechte für die gebundenen Daten des Formulars hat. Letzteres legen wir direkt fest. Wenn lngMaxBerechtigungID <\/b>einen Wert größer als 2 <\/b>hat (also die Berechtigung Alle<\/b>), stellen wir die Eigenschaften AllowDeletions<\/b>, AllowAdditions <\/b>und AllowEdits <\/b>auf den Wert True <\/b>ein, anderenfalls auf den Wert False<\/b>. Damit wäre also sichergestellt, dass der Benutzer nur lesende Rechte erhält, wenn er nicht die Berechtigung Alle <\/b>hat.<\/p>\n Neben den Berechtigungen für das Formular liefert spObjektberechtigungen <\/b>ja noch die Berechtigungen für die einzelnen Steuer-elemente, sofern diese explizit festgelegt sind. In diesem Fall entscheiden wir nur, ob das Steuer-element aktiviert ist oder nicht. Hat lngMaxBerechtigungID <\/b>einen Wert größer 1<\/b>, also die Berechtigung Lesen <\/b>oder Alle<\/b>, wird das Steuer-element aktiviert. Anderenfalls erhält die Eigenschaft Enabled <\/b>den Wert False<\/b>. Schließlich weisen wir bolForm <\/b>dem Rückgabewert der Funktion BerechtigungAnwenden <\/b>zu.<\/p>\n Nun brauchen wir nur noch dafür zu sorgen, dass das Formular die Funktion BerechtigungAnwenden <\/b>auch nutzt. Dazu nutzen wir die Ereigniseigenschaft Beim öffnen<\/b>.<\/p>\n Für diese legen wir die folgende Ereignisprozedur an:<\/p>\n Die Prozedur ruft die Funktion BerechtigungenAnwenden <\/b>mit einem Verweis auf das Formular selbst auf und prüft, ob das Ergebnis den Wert False <\/b>enthält. In diesem Fall stellt die Prozedur den Wert des Parameters Cancel <\/b>auf True <\/b>ein, was dazu führt, dass das öffnen des Formulars abgebrochen wird.<\/p>\n Sie können die Funktion in Access nun genau wie beim SQL Server Management Studio im Kontext verschiedener Benutzer testen. Dazu klicken Sie wieder bei gedrückter Umschalttaste mit der rechten Maustaste auf die Anwendung (hier MSAccess.exe<\/b>) und wählen den Eintrag Als anderer Benutzer ausführen <\/b>aus. Bevor Sie das tun, ist allerdings noch ein weiterer Schritt nötig: Die Datenbank, die Sie testen wollen, liegt ja vermutlich in einem Verzeichnis, dass dem aktuell auf dem Windows-Rechner angemeldeten Benutzer gehört. Auf dieses haben Sie keinen Zugriff, wenn Sie sich im Kontext eines anderen Benutzers anmelden. Also kopieren Sie die Datenbank zunächst in den öffentlichen Ordner des aktuellen Windows-Rechners. Danach können Sie die Datenbank von dort öffnen.<\/p>\n Es gibt einen Sonderfall, den wir beachten müssen: Wir haben hier die Gruppen Berechtigungsadministrator<\/b>, Management <\/b>und Bestellannahme <\/b>angelegt, die wir auch als Anmeldung dem SQL Server und der Datenbank Suedsturm_SQL <\/b>zugewiesen haben. Allerdings kann es ja auch sein, dass sich der Benutzer unter einem Benutzerkonto anmeldet, dass keiner dieser Gruppen angehört. Dann liefert auch die gespeicherte Prozedur spObjektberechtigungen <\/b>keine Datensätze. Sprich: Nach aktueller Programmierung gehen wir in diesem Fall davon aus, dass der Benutzer alle Rechte an allen Formularen und Steuerelementen der Datenbank hat. Diese Sicherheitsloch wollen wir noch stopfen.<\/p>\n Die Frage ist nur, wo wir das erledigen – in der gespeicherten Prozedur spObjektberechtigungen <\/b>oder in der Funktion BerechtigungenAnwenden<\/b> Am einfachsten gelingt dies in der VBA-Funktion BerechtigungenAnwenden<\/b>. Hier können wir zusätzlich prüfen, ob das Recordset keine Werte enthält. Die Erweiterung fällt recht knapp aus, denn wir prüfen nach dem öffnen des Recordsets schlicht, ob dieses keine Datensätze enthält (rst.EOF = True<\/b>). In diesem Fall stellen wir bolForm <\/b>auf False <\/b>ein, anderenfalls durchlaufen wir wie gewohnt die Datensätze des Recordsets:<\/p>\n Wenn Sie sich nun mit einem Benutzerkonto anmelden, dass nicht zu einer Benutzergruppe gehört, die der Datenbank als Anmeldung zugewiesen ist, werden Formulare, die BerechtigungenAnwenden aufrufen, nicht mehr geöffnet.<\/p>\n In der Beispieldatenbank haben wir der Schaltfläche cmdGO <\/b>des Formulars frmIntro <\/b>eine Prozedur zugewiesen, welche das Formular frmBerechtigungen <\/b>öffnet und das Formular frmIntro <\/b>schließt:<\/p>\n Wenn wir die Anwendung nun im Kontext eines Benutzers öffnen, der zwar die Berechtigung zum öffnen des Formulars cmdIntro <\/b>und zum Betätigen der Taste cmdGo <\/b>hat, aber für den für das Formular frmBerechtigungen <\/b>die Berechtigung Keine <\/b>festgelegt ist, bricht die im Formular frmBerechtigungen <\/b>definierte Ereignisprozedur für das Ereignis Beim öffnen <\/b>das öffnen des Formulars durch Setzen von Cancel <\/b>auf den Wert True <\/b>ab. Wenn dies bei einem mit DoCmd.OpenForm <\/b>geöffneten Formular passiert, löst dies allerdings für diese Anweisung den Fehler 2501<\/b>, Die Aktion OpenForm wurde abgebrochen<\/b>, aus.<\/p>\n Dies können Sie durch Deaktivieren der eingebauten Fehlerbehandlung und anschließendes Prüfen der Fehlernummer unterbinden und durch eine entsprechende Meldung erläutern:<\/p>\n Wenn Sie eine solche Anwendung weitergeben und sicherstellen wollen, dass die Berechtigungen auch tatsächlich durchgesetzt werden, sollten Sie die Access-Datenbank in eine .accde<\/b>-Datei umwandeln. Anderenfalls kann der Benutzer den VBA-Code nach seinen Wünschen ändern und beispielsweise einfach die Form_Open<\/b>-Prozeduren so ändern, dass die Abfrage der Berechtigungen gar nicht mehr erfolgt.<\/p>\n Da wir eine Menge beteiligte Komponenten bei der Verwaltung und Durchsetzung der Berechtigungen verwenden, schauen wir uns nochmal im überblick an, welche Schritte nötig sind. Zunächst die Voraussetzungen:<\/p>\n Dann die notwendigen Schritte:<\/p>\n\n
\n
Berechtigungen ermitteln per gespeicherter Prozedur<\/h2>\n
\n
net user \/add \"Peter Gross\"\r\nnet user \/add \"Harry Klein\"<\/pre>\n
net localgroup \/add Bestellannahme\r\nnet localgroup \/add Management<\/pre>\n
net localgroup Management \/add \"Peter Gross\"\r\nnet localgroup Bestellannahme \/add \"Harry Klein\"<\/pre>\n
net user<\/pre>\n
net localgroup<\/pre>\n
net localgroup Management<\/pre>\n
net user \"Peter Gross\"<\/pre>\n
![\"Einrichten](\"..\/fileadmin\/_temp_\/2019_02\/pic_1185_001.png\")
<\/p>\nGe-spei-cher-te Pro-ze-dur sp-Objekt-be-rech-ti-gungen erstellen<\/h2>\n
CREATE PROCEDURE [dbo].[spObjektberechtigungen]\r\n @Objekt varchar(255)\r\nAS\r\nSELECT\r\n(\r\n SELECT COUNT(*)\r\n FROM dbo.tblObjekteBenutzergruppenBerechtigungen t1 INNER JOIN dbo.tblBenutzergruppen t2\r\n ON t1.BenutzergruppeID = t2.BenutzergruppeID\r\n WHERE t1.ObjektID = t4.ObjektID AND IS_MEMBER(t2.Bezeichnung) = 1\r\n) AS AnzahlFestgelegterBerechtigungen,\r\n(\r\n SELECT COUNT(*) \r\n FROM dbo.tblBenutzergruppen t3 \r\n WHERE IS_MEMBER(t3.Bezeichnung) = 1\r\n) AS AnzahlGruppenDesBenutzers, \r\nt4.ObjektID, t6.Bezeichnung, MAX(t4.BerechtigungsstufeID) AS MaxBerechtigungID \r\nFROM \r\n(\r\n (\r\n dbo.tblObjekteBenutzergruppenBerechtigungen t4 INNER JOIN dbo.tblBerechtigungsstufen t5 \r\n ON t4.BerechtigungsstufeID = t5.BerechtigungsstufeID\r\n )\r\n INNER JOIN dbo.tblObjekte t6 ON t4.ObjektID = t6.ObjektID\r\n)\r\nINNER JOIN dbo.tblBenutzergruppen t7 ON t4.BenutzergruppeID = t7.BenutzergruppeID\r\nWHERE t6.Uebergeordnet = @Objekt\r\nAND IS_MEMBER(t7.Bezeichnung) = 1\r\nGROUP BY t6.Bezeichnung, t4.ObjektID;<\/pre>\n
![\"Erteilen](\"..\/fileadmin\/_temp_\/2019_02\/pic_1185_002.png\")
<\/p>\nAufbau der gespeicherten Prozedur spObjektberechtigungen<\/h2>\n
t6.Uebergeordnet = ''''frmIntro''''<\/pre>\n
IS_MEMBER(t7.Bezeichnung) = 1<\/pre>\n
(\r\n SELECT COUNT(*)\r\n FROM dbo.tblObjekteBenutzergruppenBerechtigungen t1 \r\n INNER JOIN dbo.tblBenutzergruppen t2\r\n ON t1.BenutzergruppeID = t2.BenutzergruppeID\r\n WHERE t1.ObjektID = t4.ObjektID \r\n AND IS_MEMBER(t2.Bezeichnung) = 1\r\n) AS AnzahlFestgelegterBerechtigungen<\/pre>\n
(\r\n SELECT COUNT(*) \r\n FROM dbo.tblBenutzergruppen t3 \r\n WHERE IS_MEMBER(t3.Bezeichnung) = 1\r\n) AS AnzahlGruppenDesBenutzers<\/pre>\n
Im Kontext eines anderen Benutzers am SQL Server anmelden<\/h2>\n
![\"Anwendung](\"..\/fileadmin\/_temp_\/2019_02\/pic_1185_003.png\")
<\/p>\n![\"Gespeicherte](\"..\/fileadmin\/_temp_\/2019_02\/pic_1185_004.png\")
<\/p>\n![\"Ergebnis](\"..\/fileadmin\/_temp_\/2019_02\/pic_1185_005.png\")
<\/p>\n![\"Ergebnis](\"..\/fileadmin\/_temp_\/2019_02\/pic_1185_006.png\")
<\/p>\n![\"Ergebnis](\"..\/fileadmin\/_temp_\/2019_02\/pic_1185_007.png\")
<\/p>\nVBA-Funktion zur Ermittlung der Zugriffsrechte<\/h2>\n
Public Function <\/span>BerechtigungenAnwenden(frm As <\/span>Form)\r\n Dim <\/span>rst As <\/span>DAO.Recordset\r\n Dim <\/span>bolForm As Boolean<\/span>\r\n Dim <\/span>lngMaxBerechtigungID As Long<\/span>\r\n Set<\/span> rst = SPRecordsetMitParameter(\"spObjektberechtigungen\", _\r\n Standardverbindungszeichenfolge, frm.Name)\r\n bolForm = True<\/span>\r\n Do While<\/span> Not<\/span> rst.EOF\r\n If <\/span>rst!AnzahlGruppenDesBenutzers > rst!AnzahlFestgelegterBerechtigungen Then<\/span>\r\n lngMaxBerechtigungID = 3\r\n Else<\/span>\r\n lngMaxBerechtigungID = rst!MaxberechtigungID\r\n End If<\/span>\r\n Select Case rst!Element\r\n Case <\/span>\"Form\"\r\n bolForm = lngMaxBerechtigungID > 1\r\n frm.AllowDeletions = lngMaxBerechtigungID > 2\r\n frm.AllowAdditions = lngMaxBerechtigungID > 2\r\n frm.AllowEdits = lngMaxBerechtigungID > 2\r\n Case Else<\/span>\r\n frm.Controls(rst!Element).Enabled = lngMaxBerechtigungID > 1\r\n End Select<\/span>\r\n rst.MoveNext<\/span>\r\n Loop<\/span>\r\n BerechtigungenAnwenden = bolForm\r\nEnd Function<\/span><\/pre>\nFormular mit Aufruf von „Be-rech-tigung-An-wen-den“ ausstatten<\/h2>\n
Private Sub <\/span>Form_Open(Cancel As Integer<\/span>)\r\n If <\/span>BerechtigungenAnwenden(Me) = False<\/span> Then<\/span>\r\n Cancel = True<\/span>\r\n End If<\/span>\r\nEnd Sub<\/span><\/pre>\nTesten unter verschiedenen Benutzern<\/h2>\n
Sonderfall: Keine SQL Server-Gruppenzugehörigkeit<\/h2>\n
Public Function <\/span>BerechtigungenAnwenden(frm As <\/span>Form)\r\n ...7\r\n Set<\/span> rst = ...\r\n bolForm = True<\/span>\r\n If <\/span>rst.EOF Then<\/span>\r\n bolForm = False<\/span>\r\n Else<\/span>\r\n ... Schleife durchlaufen\r\n End If<\/span>\r\n BerechtigungenAnwenden = bolForm\r\nEnd Function<\/span><\/pre>\nDas Problem mit Fehler 2501<\/h2>\n
Private Sub <\/span>cmdGo_Click()\r\n DoCmd.OpenForm \"frmBerechtigungen\"\r\n DoCmd.Close acForm, Me.Name\r\nEnd Sub<\/span><\/pre>\nPrivate Sub <\/span>cmdGo_Click()\r\n On Error Resume Next<\/span>\r\n DoCmd.OpenForm \"frmBerechtigungen\"\r\n If <\/span>Err.Number = 2501 Then<\/span>\r\n MsgBox<\/span> \"Das Formular konnte nicht geöffnet werden.\"\r\n End If<\/span>\r\n On Error GoTo<\/span> 0\r\n DoCmd.Close acForm, Me.Name\r\nEnd Sub<\/span><\/pre>\nCode sichern<\/h2>\n
Schritt für Schritt<\/h2>\n
\n