WebDAV-Repository-Manager
Mit einem WebDAV-Repository-Manager greifen Sie auf einen WebDAV-fähigen Remote-Server zu und stellen seine Inhalte für den Lese- und Schreibzugriff im Content-Management (CM) zur Verfügung.
Weitere Informationen zu „Web-based Distributed Authoring and Versioning“ finden Sie unter WebDAV.
● In der KM-Systemlandschaft ist ein HTTP-System registriert.
● Für den WebDAV-Repository-Manager ist ein Cache angelegt.
Die Funktionen des WebDAV-Repository-Managers hängen von den Funktionen des WebDAV-fähigen Remote-Servers ab. Die folgende Tabelle enthält einen Auszug der Funktionen verschiedener Server, zu denen eine Verbindung über das WebDAV-Repository hergestellt werden kann:
Funktionen der WebDAV-Server
|
EP mit CM-Repository |
Apache moddav |
MS Internet Information Server 5.0 |
RFC 2518 |
ja |
ja |
ja |
XML-Eigenschaften |
ja |
ja |
teilweise (geschachtelte Namensräume) |
Collection Locks |
ja |
ja |
nein |
Deep Locks |
ja |
ja |
nein |
Sortierte Collections |
ja |
nein |
nein |
Redirect-Verweise |
intern/extern |
nein |
nein |
Versionsverwaltung (Delta V) |
ja |
nein |
nein |
Das WebDAV-Repository setzt Caching ein, um „Rundreisen“ zum Remote-Server überflüssig zu machen und die Performance zu verbessern. Das Caching geschieht bei Systemen, die eine Authentifizierung erfordern, pro Benutzer. Das hat folgende Auswirkungen:
· Wenn der Remote-Server anonymen Zugriff zulässt, wird ein einziger Cache verwendet. Dadurch stehen Änderungen an Ressourcen sofort für alle Benutzer des Repository zur Verfügung.
· Wenn der Remote-Server eine Authentifizierung erfordert, hat jeder Benutzer einen eigenen Cache. Dadurch hängt die Zeitspanne, nach der Änderungen von anderen Benutzern festgestellt werden können, vom Cache-Timeout ab.
Der Cache behält Informationen über nicht verfügbare Ressourcen, wenn er eine 404-Antwort vom Remote-Server erhält. Diese Informationen werden mit einem sehr kurzen Timeout-Intervall gespeichert. Ein „böswilliger“ Client kann jedoch in einer kürzeren Zeit als dem Timeout-Intervall eine Suche nach nicht vorhandenen Ressourcen durchführen, was zu einem ständigen Anwachsen des Cache führt.
Wenn ein CM-Repository als WebDAV-Repository genutzt wird, werden interne als auch externe Links unterstützt.
Die Versionsverwaltung (WebDAV DeltaV) kann genutzt werden, soweit der Remote-Server dies unterstützt. Das schließt die Grundfunktionen von DeltaV ein, z.B. versionierbare Ressource, versionsgesteuerte Ressourcen und Versionsressourcen in Verbindung mit den Methoden VERSION-CONTROL, CHECKIN, CHECKOUT, UNCHECKOUT und REPORT (Versionsbaum). Erweiterte DeltaV-Funktionen wie z.B. Aktivität, Baselines oder Workspaces werden nicht unterstützt.
Der Repository-Manager kann Benutzer beim Remote-Server authentifizieren. Basis- und Digest-Authentifizierung werden unterstützt.
Jedes Repository hat eine obligatorische System-ID. Das System wird über den Systemlandschafts-Service ermittelt (siehe HTTP-System).
Wenn Sie möchten, dass alle Requests an einen Remote-Server mit demselben Benutzernamen und Kennwort durchgeführt werden, müssen Sie die Parameter User und Password im HTTP-System definieren. Wenn das WebDAV-Repository diese Informationen im System findet, werden alle anderen Zuordnungen ignoriert, und Requests werden mit diesem Benutzer und diesem Kennwort ausgeführt, unabhängig vom lokalen Benutzer.
Die vom WebDAV-Repository verwendeten HTTP-Klassen unterstützen Basis-, Digest- und NTLM-Authentifizierung. Die Verbindung kann einfach oder über SSL/TLS hergestellt werden. SSL/TLS über HTTP-Proxies wird unterstützt.
Requests an den Remote-Server werden anonym gestartet. Der Remote-Server muss eine Authentifizierung anfordern, um den Benutzer zu identifizieren. Wie zuvor bereits erwähnt, kann das WebDAV-Repository so konfiguriert werden, dass ein bestimmter Benutzer für alle Requests verwendet wird (unabhängig vom lokalen Benutzer).
Die Basis-Authentifizierung über nicht verschlüsselte Links ist ein Sicherheitsrisiko, da Kennwörter fast im Klartext gesendet werden. Zur Zeit gibt es keine Möglichkeit zu verhindern, dass die Basis-Authentifizierung ohne SSL/TLS stattfindet.
Wenn Sie auf einen Remote-WebDAV-Server zugreifen, der ebenfalls ein Portal mit KM ist, können Sie den Sicherheitsmanager WDAclSecurityManager verwenden.
Voraussetzung: In der Konfiguration des WebDAV-Protokolls ist Extension ACL aktiviert.

Die Haupteinschränkung des WDAclSecurityManager besteht darin, dass der Remote-Server in derselben Benutzerdomäne laufen muss. Die Benutzer des Remote-Servers sollten mit den lokalen Benutzern übereinstimmen.
Für andere WebDAV-Server werden keine eigenen Sicherheitsmanager angeboten.
Parameter eines WebDAV-Repository-Managers
Parameter |
Obligat. |
Beschreibung |
Name |
ja |
Name des Repository-Managers |
Description |
nein |
nähere Beschreibung des Repository-Managers |
Prefix |
ja |
bezeichnet den Namen (URI-Präfix), unter dem das Repository im root-Verzeichnis aufgelistet wird |
Active |
nein |
Sie können den Repository-Manager durch Setzen des Parameters (de)aktivieren. |
Hide in Root Folder |
nein |
gibt an, ob das Repository im Stammverzeichnis aufgelistet wird Wenn Sie den Parameter aktivieren, wird das Repository nicht im Stammverzeichnis aufgelistet. |
System ID (Landscape Service) |
ja |
Angabe eines HTTP-System, das in der CM-Systemlandschaft registriert ist |
System Path |
nein |
optionales Suffix für die Server-URL des Remote-Systems Die Server-URL ist eine Eigenschaft des (Landschafts-)Systems. System Path ermöglicht es, für verschiedene Pfade im URL-Namensraum dasselbe System zu verwenden. |
Use System Default Proxy Settings |
nein |
legt fest, ob die Einstellungen des Standard-Proxy-Systems verwendet werden |
Proxy System ID (Landscape Service) |
nein |
Angabe der ID eines Proxyservers aus dem Systemlandschafts-Service Dieser Parameter sollte anstelle von Proxy Host genutzt werden, wenn der Proxyserver Authentifizierung voraussetzt. |
Proxy Host |
nein |
Host-Name eines HTTP-Proxy, der für dieses Repository verwendet werden soll Alternativ können Sie den Parameter Use System Default Proxy Settings aktivieren. |
Proxy Port |
nein |
Port-Nummer, unter der der Proxy auf Proxy Host erreichbar ist |
Repository Services |
nein |
Identifikationen der Repository-Services, die Sie für ein Repository verwenden möchten Beachten Sie, dass der Statusverwaltungs-Service (statemngt) den Service-ACL-Service (svc_acl) und Application-Property-Service (properties) verlangt. Der zeitabhängige Publishing-Service sollte hier nur dann genutzt werden, wenn Sie sicherstellen können, dass nur der Repository-Manager auf die Dokumente zugreift. |
Property Search Manager |
nein |
Auswahl des Managers für die Suche nach Eigenschaften Wählen Sie den WDPropertySearchManager. |
Versioning Manager |
nein |
Java-Klasse, die den Sub-Manager für die
Versionsverwaltung implementiert: |
Security Manager |
nein |
Auswahl eines Sicherheitsmanagers, der den Zugriff auf die Repository-Inhalte steuert Wenn Sie auf einen Remote-WebDAV-Server zugreifen, der ebenfalls ein Portal mit KM ist, wählen Sie den Sicherheitsmanager WDAclSecurityManager. Für andere WebDAV-Server werden keine eigenen Sicherheitsmanager angeboten. |
ACL Manager Cache |
nein |
Identifikation des Cache für Ressourcen-ACLs: rsrcacl Dieser Parameter wird benötigt, wenn ein ACL-Sicherheitsmanager im Parameter Security Manager angegeben ist. |
Read-only ACLs |
nein |
legt fest, ob der Sicherheitsmanager Änderungen der Zugriffskontrolllisten zulassen soll oder ob sie schreibgeschützt sein sollen Standardmäßig ist dieser Parameter deaktiviert. |
Send Events |
nein |
gibt an, ob das Repository Ereignisse sendet, wenn Operationen wie „Löschen", „Inhalt aktualisieren" usw. bei Ressourcen durchgeführt werden Damit das Repository Ereignisse sendet, muss der Parameter den Wert true haben. Das ist z.B. für die Verwendung von Services wie dem Subskriptionsservice erforderlich. Standardmäßig ist dieser Parameter aktiviert. |
Memory Cache |
ja |
Identifikation eines Memory-Cache, der vom WebDAV-Repository für das Caching von Dateien und Ordnern verwendet werden soll |
Cache Timeout |
nein |
Timeout in Millisekunden für Ressourcen im Cache Nach diesem Zeitintervall wird die Ressource (spätestens) erneut gegen den Remote-Server geprüft. Der optimale Wert hängt von der Erreichbarkeit des Remote-Servers ab. |
HTTP Timeout |
nein |
Timeout in Millisekunden, nachdem Operationen auf dem Server abgebrochen werden Beispiel: 180000 ms = drei Minuten. Der Standardwert ist 0, d. h. unendlich (kein Timeout). Die Leerlaufzeit ist die Zeit zwischen erfolgreichen Lese-/Schreiboperationen. Wenn der Remote-Server z.B. einen Request nicht im vorgegebenen Zeitintervall beantwortet, wird der Request als gescheitert betrachtet, und ein Fehler wird gemeldet. Beachten Sie, dass zu diesem Zeitpunkt nicht die komplette Antwort gelesen wird. Wenn der WebDAV-Repository-Manager ein großes Dokument liest, wird die Leerlaufzeit als die Zeit zwischen erfolgreichen Leseoperationen von Teildaten gezählt, nicht als die Zeit, die für das Abrufen des vollständigen Dokuments benötigt wird. (Erläuterung: HTTP Timeout legt den Wert SOTIMEOUT des Verbindungs-Socket zum Remote-Server fest). |
Server Type |
ja |
Angabe des verwendeten Servertyps Generic WebDAV Server Native IIS WebDAV Server Apache Moddav Server Wenn Sie keinen IIS oder Apache moddav Server mit diesem Repository-Manager ansprechen, wählen Sie den Eintrag Generic WebDAV Server. Die korrekte Angabe des Servertyps verringert die Anzahl von Anfragen des WebDAV-Repository-Managers an den Remote-Server, da der unterstützte Funktionsumfang durch diesen Parameter bereits festgelegt ist und nicht abgefragt werden muss. |
Um einen WebDAV-Repository-Manager anzulegen und zu konfigurieren, wählen Sie Content Management → Repository Managers → WebDAV Repository.
Siehe auch:
Integration u. Konfiguration des WebDAV-Repository-Managers
Zugriff auf Dokumente
über WebDAV
Content-Management-Ordner
als Webordner einbinden
Die Dokumente, die auf einem nativen IIS-WebDAV-Server abgelegt sind, sollen über einen WebDAV-Repository-Manager ins KM integriert werden. Der WebDAV-Server ist unter der Adresse http://webDAVserver:1090/projectshare verfügbar.
Beispiel einer WebDAV-Repository-Manager-Konfiguration:
Name =
webdav
Description = WebDAV Repsoitory
Manager
Prefix =
/webdav
System ID =
webdav
System Path = /projectshare
Cache Timeout = 5000
Memory Cache = ca_webdav
ACL Manager Cache = ca_rsrc_acl
Versioning Manager = […].WDVersioningManager
Server Type = Native IIS WebDAV
Server
Beispiel des zugehörigen HTTP-Systems:
System
ID = webdav
Description = HTTP System for WebDAV
Server-URL =
http://webDAVserver:1090
Same User Domain = Activated
max. Connections = 300