Zugriffsbeschränkung auf View

[jor]

Hallo zusammen,

die Möglichkeit Ansichten über die ACL zu schützen möchte ich hier auslassen, da es mir nicht flexibel genug ist (wechselnde Zugriffsberechtigung für Personen durch TEAM-Wechsel).
Ich stelle mir vor, dass ich im Queryopen der View ein Script hinterlege, das überprüft, ob aktueller User im Viewnamen steht, dann öffnen, wenn nicht wir dnoch ein Profildokument abgefragt, ob dort  der aktuelle Benutzer aufgeführt wird. Funzt auch soweit, aber... leider merkt sich Notes die letzte Ansicht (die Datenbank hat keinen Vorgabe Navi oder so, beim Öffnen der DB, weil zuviele Ansichten vorhanden) die benuzt wurde und nach dem Schliessen wird diese Datenbank nicht mehr geöffnet, da das Script immer noch zieht.
Ich habe auch versucht, bei unberechtigtem Zugriff eine andere Ansicht zu öffnen, geht auch, aber es bleibt immer noch der Reiter stehen, auf dem der Zugriffsversuch durchgeführt wurde, und dieser stört dann, da das Script wieder ausgeführt wird.

Hat jemand von euch sowas umgesetzt, oder kann mir ein Tipp geben?

[Axel]

die Möglichkeit Ansichten über die ACL zu schützen möchte ich hier auslassen, da es mir nicht flexibel genug ist (wechselnde Zugriffsberechtigung für Personen durch TEAM-Wechsel).

Warum?

Ich würde das Ganze über Gruppen abwickeln. Einer Ansicht wird in der Zugriffsbeschränkung diese Gruppe zugewiesen. Nur Mitglieder dieser Gruppe, dürfen auf diese Ansicht zugreifen. Nur so bekommst du die Sache wasserdicht. Alles andere hat irgendwelche Seiteneffekte.


Axel

[jor]

Hi Axel,

jep, so wie du es schreibst ist es vollkommen richtig. Die Lösung über Gruppen wollte ich nicht
so gerne umsetzen, weil die einzelnen Teammitglieder öfter wechseln. Dadurch hätten wir, die
Admins und ich ewig die Aufgabe die Gruppen zu pflegen. Ein Schreibzugriff
der User auf das DD möchten wir unter allen Umständen verhindern.

Aber auch nach weiterem Testen sieht es momentan so aus, als wenn wir uns die Gruppenpflege-
mütze aufsetzen müssen. 

Gruß Volker

[HH]

Warum die Gruppenpflegermütze selbst aufsetzen. Default im DD ist Autor. Damit kann der Standard-User nur bedingt in seinem Personendokument ändern. Über das Feld Administrators und die Rolle GroupModifier läßt sich steuern wer die Gruppe bearbeiten kann.

Hubert

[Driri]

Hi,

evtl. eine Alternative, erfordert aber dann etwas Programmieraufwand :

In der Datenbank werden über Konfigdokumente die Teamzugehörigkeiten administriert. Für jedes Team wird eine Rolle in der ACL angelegt und den zugehörigen Teammitgliedern zugewiesen.

Das kann man über die NotesACL und NotesACLEntry abfackeln.

Problem : Die User müßten als Person in der ACL stehen.

[jor]

Hallo Hubert,

das stimmt ja, aber ich hatte auch geschrieben, das unter allen Umständen ein schreibender Zugriff
auf das DD verhindert werden muß.

Gruß Volker

[ascabg]

@HH

Auf "GroupModifier" wuerde ich nicht unbedingt zurueckgreifen, da ein User mit dieser Role prinzipiell ALLE Gruppen modifizieren kann.

Lieber auf "Eigentuemer" und maximal "Administrator" der Gruppe zurueckgreifen, um zu regeln, wer ausser den Admins diese Gruppe noch pflegen kann.

Andreas

[jor]

Hallo Driri,

hast recht! Aber auch das ist von der Administration nicht möglich, da dann alle Benutzer in der ACL stehen und verwaltet werden müßten.

Gruß Volker

[HH]

@Andreas

Du hast natürlich recht. Owner würde vollkommen ausreichen und GroupModifier wäre des Guten viel zu viel.

Hubert

[Driri]

Noch ne andere Idee wäre, mit persönlichen Ansichten zu arbeiten, die bei jedem Öffnen der DB gekillt und neu erzeugt werden.
Dann kann man die Teamzugehörigkeit wieder über Konfigdokumente regeln und das über die Selectformel in der pers. Ansicht berücksichtigen.

Setzt allerdings dann voraus, daß nach einer Änderung der betroffenen User die Datenbank auch wirklich einmal schließt und ich weiß nicht, ob sich das in der Anwendung realisieren läßt (wegen Select-Formel).

[jor]

Hi Ingo,

das klingt interessant, aber es sieht momentan so aus, das die Sache doch mittels Gruppen im DD umgesetzt wird.

Danke Volker

[Tode]

wenn Du partout keinen Schreibzugriff aufs DD erlauben willst, dann lagere diese Gruppen halt aus in ein weiteres Adressbuch, das Du entweder mit der Pubnames oder mit der Pernames erstellst. Dieses trägst Du dann in die (Sicher vorhandene) Directory Assistance ein und "kastrierst" es ggf noch so, dass die User nur Access- Control- Only- Gruppen erstellen können, sonst nix.

Du musst halt nur in der DA eintragen, dass das Adressbuch "Group Authiorization" erlaubt...

HTH
Tode

[jor]

Hi Tode,

danke für deinen Tipp. Jep, das wäre auch eine Möglichkeit, aber es ist jetzt doch über Gruppen im DD organisiert worden, es gab Gründe, auf die ich nicht weiter eingehen werde, die die Erweiterung mit einer weiteren DB für uns nicht als vorteilhaft gelten liessen.

Dein Vorschlag gefällt mir über dies, da dadurch das DD schlank gehalten werden kann, was ich persönlcih favorisiere.

Gruß Volker