Auf dieser Website werden Cookies gesetzt, die für den sicheren Betrieb technisch erforderlich sind. Siehe: Datenschutz

Sekundäres Domino Directory erstellen, entwickeln und einbinden

von Christoph,
assono GmbH, Standort Kiel,

Voraussetzungen und Anwendungsfälle

Wie man mehrere Domino Directories verwaltet, gehört zur Grundausbildung der Notes-Administration. Wie man jedoch ein sekundäres Domino Directory anlegt bzw. in eine "normale" Datenbank integriert, scheint weniger bekannt zu sein, wenn man sich im Internet auf die Suche begibt. Und das, obwohl es mit wenigen Anpassungen ganz einfach möglich ist!

Eine der Stärken von Notes/Domino ist die Regelung von Zugriffsrechten. Dies gilt nicht nur für klassische Notes-Client-Anwendungen, sondern genauso für die weiterhin steigende Anzahl an Web-Anwendungen, die auf den Domino-Server zur Datenhaltung setzen. Dabei ist die Nutzung von Webanwendungen nicht nur für Besitzer einer Notes-ID möglich. Zusätzlich lassen sich Nutzer ohne Notes-ID anlegen, sodass auch Externe bei Bedarf unproblematisch in Prozesse eingebunden werden können. Hier kommt das sekundäre Domino-Directory ins Spiel.

Grundsätzlich lässt sich jede Datenbank als sekundäres Domino Directory nutzen. Das einzige, was man braucht, sind eine Maske mit ein paar Feldern und bestimmte Ansichten, wie sie in der klassischen names.nsf vorkommen.

1. Nutzer-Maske

Jeder Nutzer benötigt (wie auch im Adressbuch) ein persönliches Dokument. Dazu legen wir eine Maske an. Der Name der Maske spielt keine Rolle. Darin werden folgende Felder benötigt:

  • FullName: Ein Mehrfachwert-Feld vom Typ Namen. Mit den hierin hinterlegten Namen kann sich der Nutzer anmelden. Der erste Wert im Feld ist dabei der Name, unter dem der Nutzer am Ende im Web agiert. (Kleiner Tipp am Rande: Wenn das Feld berechnet ist, muss man darauf achten, dass der/ein Name in kanonischer Form eingetragen wird. Fiese Fehlerquelle...)
  • HTTPPassword: Einfaches Textfeld. Mit dem hier hinterlegten Passwort authentifiziert sich der Benutzer beim Log-In. Man sollte das Passwort natürlich nicht im Klartext hinterlegen. Es bietet sich an, als Eingabeumsetzung die Formel @HashPassword(@ThisValue) (anstelle der unsichereren Funktion @Password) zu verwenden.
  • Type: Einfaches Textfeld, das den Wert "Person" enthält. Naturgemäß bietet es sich an, dieses Feld als Berechnet beim Anlegen einzustellen.

Das genügt bereits. Wollen wir hingegen mehr als nur die notwendigen Log-In-Daten speichern, können wir die Maske problemlos erweitern und im Prinzip frei gestalten. Nehmen wir zum Beispiel an, dass wir externen Gutachtern ermöglichen möchten, Dateien hochzuladen. Dann können wir Anschrift, Geburtsdatum, Ausbildung, was auch immer wir in unserem Anwendungsfall an Informationen zum Gutachter sonst noch benötigen in der Maske mitspeichern. Es ist lediglich zu bedenken, dass die Lese- und Bearbeitungsrechte so eingestellt sein sollten, dass Unbefugte nicht aus Versehen die Anmeldedaten ändern oder gar auslesen können.

Die Felder FullName, HTTPPassword und Type sind zwingend für Nutzer-Dokumente.

2. Nutzer-Ansicht(en)

In der Anwendung muss die Ansicht "($Users)" vorhanden sein. Diese kann aus der Domino-Directory-Standard-Schablone (pubnames.ntf) übernommen werden. Sie dient dem Server zum Look-Up bei der Anmeldung. Wer weitere Funktionen nutzen möchte, benötigt je nach Anwendungsfall ggf. weitere Ansichten. Hier lohnt sich ein genauerer Blick in die Standard-Schablone auf die Ansichten, bei denen in der Selektionsformel Type = "Person" vorkommt.

Mit den hier hinterlegten Namen kann man sich später anmelden.

3. Zugriffskontrolle

Der Log-In funktioniert sogar wenn der Nutzer keinen Zugriff auf die Datenbank hat. Damit er jedoch (ohne eventuelle programmatische Umwege) selbst seine Daten oder sein Passwort ändern kann, ist in der Regel der Zugriff als Autor sinnvoll. Die detaillierte Konfiguration hängt vom Anwendungsfall ab. Dabei kann es sich anbieten, mit Wildcards zu arbeiten, wenn eine feste Namensstruktur bei ganzen Benutzergruppen zugrunde liegt. Dadurch muss nicht jeder Nutzer einzeln der ACL oder einer Gruppe im Domino Directory hinzugefügt werden.

ACL mit Wildcard-Ausdruck für Web-User

4. Einbindung in Directory Assistance

Nun muss man die Datenbank nur noch mit dem Server bekannt machen.

In der Datenbank "Directory Assistance" ein neues Dokument anlegen.
Im Reiter "Basics" eine Domäne eintragen. Hier ist wichtig, dass der gewählte Domänenname eindeutig ist und in keinem anderen Dokument vorkommt.
Im Reiter "Naming Context (Rules)" bei Bedarf die Wildcards "*" einschränken. Damit die Nutzung aus dem Web möglich ist, muss das Feld "Trusted for Credentials" auf "Yes" geändert werden.
Als letztes hinterlegt man im Reiter "Domino" den Server und den Datenbankpfad. Nicht vergessen, den Eintrag zu aktivieren!

5. Anmelden

Geschafft!

Nun können sich alle in der Datenbank angelegten Benutzer über den Browser anmelden.

Nächste Artikel in dieser Reihe:

Fachbeitrag HCL Notes HCL Domino Web-Entwicklung Entwicklung Für Entwickler

Sie haben Fragen zu diesem Artikel? Kontaktieren Sie uns gerne: blog@assono.de

Sie haben Interesse an diesem Thema?

Gerne bieten wir Ihnen eine individuelle Beratung oder einen Workshop an.

Kontaktieren Sie uns

Weitere interessante Artikel

Sie haben Fragen?

Wenn Sie mehr über unsere Angebote erfahren möchten, können Sie uns jederzeit kontaktieren. Gerne erstellen wir eine individuelle Demo für Sie.

assono GmbH

Standort Kiel (Zentrale)
assono GmbH
Lise-Meitner-Straße 1–7
24223 Schwentinental

Standort Hamburg
assono GmbH
Bornkampsweg 58
22761 Hamburg

Telefonnummern:
Zentrale: +49 4307 900 407
Vertrieb: +49 4307 900 402

E-Mail-Adressen:
kontakt@assono.de
bewerbung@assono.de