Das Notes Forum

Domino 9 und frühere Versionen => ND7: Entwicklung => Thema gestartet von: jr am 12.03.09 - 12:57:52

Titel: Zugriffsrechte eines Benutzers feststellen
Beitrag von: jr am 12.03.09 - 12:57:52
Hallo zusammen,

meine Frage ist einfach: Wie bestimme ich das Benuzerrecht irgend eines Anwenders auf eine Datenbank?

Es geht darum, dass ich einen Namen habe und wissen möchte, welche Rechte er auf eine Datenbank hat. Dies ist nicht unbedingt der angemeldete Benutzer! Jetzt steht der Benutzer ja nicht zwangsläufig mit seinem voll qualifizierten Namen in der ACL, sondern taucht vielleicht in einer oder mehreren Gruppen auf. Mit session.UserGroupNameList komme ich nicht weiter, weil das erstens nur den aktuellen Benutzer betrifft zweitens können da ja immer noch mehrere Einträge zutreffen (wenn mehrere Gruppen greifen). Also, wie bekomme ich heraus, welche ACL-Eintrag für diesen Benutzer greift?

Kann mir da irgend jemand helfen? Vielleicht stehe ich auch nur auf dem Schlauch und das Problem ist trivial zu lösen. Bin für jede Idee dankbar...

Im Voraus vielen Dank für Eure Antworten,

Joachim
Titel: Re: Zugriffsrechte eines Benutzers feststellen
Beitrag von: m3 am 12.03.09 - 13:05:19
ACL öffnen -> Effective Access anklicken -> Benutzernamen eingeben -> Calculate Access anklicken
Titel: Re: Zugriffsrechte eines Benutzers feststellen
Beitrag von: jr am 12.03.09 - 13:13:52
Danke für die schnelle Antwort, aber das beantwortet leider nicht meine Frage.

Wenn der Benutzer XY nicht in der ACL steht, dann greift irgend eine Gruppe, und woher weißt Du dann welche das ist? Außerdem muss ich das berechnen, brauche also eine LS oder @Formel-Lösung. Gibt es eine Funktion, die diesen "Effective Access" liefert?

Gruß,

Joachim
Titel: Re: Zugriffsrechte eines Benutzers feststellen
Beitrag von: DerAndre am 12.03.09 - 13:20:13
Aus der Notes ACL Klasse die Methode GetEntry sollte Dir helfen können.
Titel: Re: Zugriffsrechte eines Benutzers feststellen
Beitrag von: jr am 12.03.09 - 13:26:40
Hallo,

nein, leider nicht, denn da muss ich genau den Namen des ACL-Eintrags einragen. Wie gesagt, es geht darum, welcher dieser Einträge für einen bestimmten Benuzter greift. Wenn ich den weiß, dann kann ich mit GetEntry den Eintrag holen.

Gruß,

Joachim
Titel: Re: Zugriffsrechte eines Benutzers feststellen
Beitrag von: klaussal am 12.03.09 - 13:30:43
Lies mal unter @UserAccess nach.
Titel: Re: Zugriffsrechte eines Benutzers feststellen
Beitrag von: DerAndre am 12.03.09 - 13:51:39
UserAccess geht aber wieder nur für den aktuellen Benutzer.

Eigentlich musst Du alles zu Fuß aufdröseln
Titel: Re: Zugriffsrechte eines Benutzers feststellen
Beitrag von: m3 am 12.03.09 - 13:56:40
Danke für die schnelle Antwort, aber das beantwortet leider nicht meine Frage.
Doch. Die gestellte Frage wurde korrekt und vollständig beantwortet.

Zitat
Wenn der Benutzer XY nicht in der ACL steht, dann greift irgend eine Gruppe, und woher weißt Du dann welche das ist?
Das Tool zeigt an, welche Gruppen/Rollen greifen.

Zitat
Außerdem muss ich das berechnen, brauche also eine LS oder @Formel-Lösung. Gibt es eine Funktion, die diesen "Effective Access" liefert?
Hmmm. Davon lese ich nix in der ursprünglich gestellten Frage. Und meine Kristallkugel ist schon im Wochenende.

Ich denke, Du wirst nicht umhin kommen, die ACL-Einträge manuell durchzuwassern, Gruppen aufzulösen und Dir die Infos manuell zusammen zu bauen, @UserAccess liefert ja auch nicht das "warum" zur Info.
Titel: Re: Zugriffsrechte eines Benutzers feststellen
Beitrag von: Tim Pistor am 12.03.09 - 14:28:58
Es gäbe noch

NotesDatabase.QueryAccess( name$ )

Titel: Re: Zugriffsrechte eines Benutzers feststellen
Beitrag von: DerAndre am 12.03.09 - 14:45:38
Der QueryAccess ist ja mal cool.

Also nicht zu Fuß sondern QueryAccess, wieder was gelernt...
Titel: Re: Zugriffsrechte eines Benutzers feststellen
Beitrag von: jr am 12.03.09 - 17:05:22
Vielen Dank für Eure Hilfe.

QueryAccess kannte ich noch nicht, und das scheint das richtige zu ein. Dazu gibts noch QueryAccessPrivileges und QueryAccessRoles, womit man eigentlich alles bekommen sollte. Ich habs jetzt nur kurz getestet und für den voll qualifzierten Namen, der explizit in der ACL steht, funktioniert es einwandfrei. Wenn ich nur den Common Name angebe, klappt es derzeit noch nicht und wenn der Name nur in einer Gruppe auftaucht leder auch nicht.

Das kann aber an mir liegen, weil ich irgend etwas falsch gemacht habe. Da schau 'mer mal...

Nochmals Danke,

Joachim
Titel: Re: Zugriffsrechte eines Benutzers feststellen
Beitrag von: koehlerbv am 12.03.09 - 17:28:13
Der Common Name geht selbstverständlich nicht, denn zwischen "CN=Kuno Killerkarpfen/O=Teich/C=Natur" und "Kuno Killerkarpfen" besteht nun mal ein himmelweiter Unterschied.

Wegen der Gruppen: Du testest aber nicht lokal, oder?

Ansonsten: Benutze mal die Suche des Forums nach dem Begriff "queryaccess" - Du wirst da weitere interessante Sachen finden.

Bernhard
Titel: Re: Zugriffsrechte eines Benutzers feststellen
Beitrag von: jr am 12.03.09 - 18:14:20
So, jetzt hab ich mal verschiedene Dinge getestet und die anderen Beiträge zu QueryAccess in diesem Forum gelesen. Ein Manko ist wohl, dass nur das Adressbuch durchsucht wird, das da liegt, wo das Skript ausgeführt wird. Das kann man mit einem einfachen "Doppelagenten" umgehen (also ein Agent, der einen anderen Agenten auf dem Server aufruft). Die umständliche Parameterübergabe kann man verkraften, wenn es hart auf hart kommt, dann nimmt man das Environment.

Schlimmer ist, dass nur das primäre Adressbuch durchsucht wird denn das ist bei meinen Kunden tödlich, weil es dort Weba- und Gruppenadressbücher gibt.

@Bernhard: Das es mit dem Common Name nicht geht find ich gar nicht so selbstverständlich, denn über den "Effective Access"-Button geht das auch. Er fragt zwar kurz nach, ob es sich um eine Gruppe handelt, berechnet dann aber korrekt den Zuriff. Und ansonsten funktioniert ja der CN auch überall (Autorenfelder, Leserfelder, Adressdialog, etc.). Ist nicht wirklich schön (und wird von mir auch tunlichst vermieden), aber es funktioniert. Und bei den Namen, die in der "Groups and Roles"-Dialog-Box erscheinen steht ja auch der CN mit drin drin.

Die Funktion "Effective Access" der ACL, das wäre genau das, was ich brauche, nur in LotusScript halt...  ;D

Naja, vielleicht in Version 17.5 ....

Nochmals Danke für Eure Hilfe.

Gruß,

Joachim
Titel: Re: Zugriffsrechte eines Benutzers feststellen
Beitrag von: koehlerbv am 12.03.09 - 18:19:22
Und ansonsten funktioniert ja der CN auch überall (Autorenfelder, Leserfelder, Adressdialog, etc.). Ist nicht wirklich schön (und wird von mir auch tunlichst vermieden), aber es funktioniert.

Ui, dann hast Du damit aber noch nicht viel gemacht und dadurch erlebt. Die Dokumentationen sprechen auch immer eine andere Sprache.

Bernhard
Titel: Re: Zugriffsrechte eines Benutzers feststellen
Beitrag von: jr am 12.03.09 - 18:39:26
lol - ne, nicht wirklich. Wie gesagt vermeide ich das, weil es bäh ist.

Aber ich kenne genug Datenbanken, die ausschließlich mit dem CN arbeiten, auch bei meinen Kunden...

JR
Titel: Re: Zugriffsrechte eines Benutzers feststellen
Beitrag von: ata am 13.03.09 - 09:02:09
Zitat
Die Funktion "Effective Access" der ACL, das wäre genau das, was ich brauche, nur in LotusScript halt... 

... mit Evaluate tut das auch in Script entsprechend

Toni
Titel: Re: Zugriffsrechte eines Benutzers feststellen
Beitrag von: Glombi am 13.03.09 - 09:21:30
lol - ne, nicht wirklich. Wie gesagt vermeide ich das, weil es bäh ist.

Aber ich kenne genug Datenbanken, die ausschließlich mit dem CN arbeiten, auch bei meinen Kunden...

JR
Das funktioniert dann und nur dann, wenn alle User- und Server-IDs, auf denen die Datenbank betrieben wird, vom selbem Certifier abstammen.
Und das kann sich ja irgendwann ändern... Und schon hat man ein riesiges Problem.

Andreas
Titel: Re: Zugriffsrechte eines Benutzers feststellen
Beitrag von: jr am 13.03.09 - 09:33:46
Zitat
Das funktioniert dann und nur dann, wenn alle User- und Server-IDs, auf denen die Datenbank betrieben wird, vom selbem Certifier abstammen.
Und das kann sich ja irgendwann ändern... Und schon hat man ein riesiges Problem.

Oder, und das ist bei einem Kunden passiert, wenn ein Mitarbeiter mit einem gleichen Namen kommt. Der urspüngliche Entwickler war nicht mehr verfügbar und so musste ich die komplette Datenbank umbauen.

Joachim