WebDAV - Versionsgeschichte

Netbreaker: /* XP */

2010-06-20T17:27:24Z

‎XP

Netbreaker am 20. Juni 2010 um 14:31 Uhr

2010-06-20T14:31:54Z

Netbreaker: /* XP-Clients */

2010-06-20T13:40:53Z

‎XP-Clients

Netbreaker: /* XP-Clients */

2010-06-20T13:28:14Z

‎XP-Clients

Netbreaker: /* XP-Clients */

2010-06-20T13:10:47Z

‎XP-Clients

Netbreaker: /* XP-Clients */

2010-06-20T13:09:35Z

‎XP-Clients

Netbreaker: Die Seite wurde neu angelegt: ==WebDAV== ===ServerConfig (apache2)=== In der Konfiguration des SSL-VirtHosts des apache sind folgende Einstellungen einzutragen:
...

2010-06-20T13:08:14Z

Die Seite wurde neu angelegt: ==WebDAV== ===ServerConfig (apache2)=== In der Konfiguration des SSL-VirtHosts des apache sind folgende Einstellungen einzutragen: <VirtualHost *:443> ...

Neue Seite

==WebDAV==

===ServerConfig (apache2)===

In der Konfiguration des SSL-VirtHosts des apache sind folgende Einstellungen einzutragen:

<VirtualHost *:443> 
... 
<Directory /srv/dav/test>
Options Indexes
AllowOverride None
AuthType Digest
AuthName WebDAV-Test
AuthDigestDomain /dav-test https://ssl.bamsenet.de/dav-test
AuthDigestProvider file
AuthUserFile /srv/dav/.htdigest-passwd
</Directory> 
Alias /dav-test /srv/dav/test
<Location /dav-test>
DAV On
SSLRequireSSL
<LimitExcept OPTIONS>
Require user testuser
</LimitExcept>
<Limit OPTIONS HEAD GET PROPFIND>
Require valid-user
</Limit>
</Location> 
... 
</VirtualHost>

Den Benutzer für den obigen Zugriff erzeugen: 
htdigest -c /srv/dav/.htdigest-passwd WebDAV-Test testuser

Weitere Benutzer werden ohne der Option '-c' hinzugefügt oder bei bestehenden Usern die Passwörter geändert.
Wichtig ist der mit der Direktive 'AuthName' gleichlautende Realm 'WebDAV-Test'.
Die Relevanz der 'AuthDigestDomain'-Angabe wurde noch nicht geprüft.

===XP-Clients===

Diverse Anleitungen treffen unterschiedliche Aussagen bzgl. der Umsetzung. Sicher ist jedoch, daß MS wieder mal den Standard nicht einhält. Während unter Linux bzw. mit einem DAVClient unter Windows (z.B. DAVExplorer) bereits alles funktioniert, ist Windows noch nicht mal in der Lage den Ordner zu finden.

WebDAV-Ordner lassen sich auf 2 Wegen anlegen:
* Windows-Explorer -> Extras -> Netzlaufwerk verbinden -> Onlinespeicherplatz anfordern
* Netzwerkumgebung -> Netzwerkressource hinzufügen

In beiden Fällen kommt man zum "Assistenten zum Hinzufügen von Netzwerkressourcen".

-> Weiter -> (andere Netzwerkressource) Weiter -> https://<HOSTNAME>/<WebDAV-Ordner> (z.B. https://ssl.bamsenet.de/dav-test) 
Falls nicht alle Workarounds für Windows in der ServerConfig vorhanden sind, erkennt Windows den DAV-Ordner hier nicht.

access.log im Erfolgsfall:
84.179.171.227 - - [20/Jun/2010:14:28:45 +0200] "PROPFIND /aronia-jtl HTTP/1.1" 401 555 "-" "Microsoft Data Access Internet Publishing Provider DAV"

Im Erfolgsfall wird der Benutzername (testuser) und das Passwort für die Ressource abgefragt, mit dem darauf zugegriffen werden soll. Passwort merken wurde dabei ebenfalls markiert. Serverseitig muß hierfür "AuthType Digest" konfiguriert sein oder in der Registry BasicAuth freigeschaltet werden. Digest ist hier allerdings die bevorzugte Variante.

access.log im Erfolgsfall:
84.179.171.227 - testuser [20/Jun/2010:14:29:16 +0200] "PROPFIND /dav-test HTTP/1.1" 207 849 "-" "Microsoft Data Access Internet Publishing Provider DAV"
84.179.171.227 - testuser [20/Jun/2010:14:29:16 +0200] "PROPFIND /dav-test HTTP/1.1" 207 849 "-" "Microsoft Data Access Internet Publishing Provider DAV"

Danach wird der Name der Ressource festgelegt und der Assistent fertiggestellt werden. Dem WebOrdner kann allerdings kein Laufwerksbuchstabe zugeordnet werden.

access.log nach dem Festlegen des Namens:
84.179.171.227 - testuser [20/Jun/2010:14:29:35 +0200] "PROPFIND /dav-test HTTP/1.1" 207 849 "-" "Microsoft Data Access Internet Publishing Provider DAV"

Das nachfolgende Öffnen des Ordners verursacht keine weiteren Einträge. Erst das öffnen eines Ordners erzeugt weitere Meldungen, jetzt allerdings mit dem lokalen Benutzernamen:
84.179.171.227 - rico [20/Jun/2010:14:35:03 +0200] "PROPFIND /dav-test/dir1 HTTP/1.1" 401 555 "-" "Microsoft Data Access Internet Publishing Provider DAV"
84.179.171.227 - rico [20/Jun/2010:14:35:03 +0200] "PROPFIND /dav-test/dir1 HTTP/1.1" 207 6482 "-" "Microsoft Data Access Internet Publishing Provider DAV"

Ab diesem Zeitpunkt ist der Inhalt sichtbar und Dateien können gelesen werden. Für den Schreibzugriff ignoriert Windows jedoch die zuvor eingegebenen Logindaten und versucht mit den Windows-Anmeldedaten darauf zuzugreifen.

Die zugehörigen Meldungen im error.log des Servers:
[Sun Jun 20 13:19:24 2010] [error] [client 84.179.171.227] Digest: user `rico' in realm `WebDAV-Test' not found: /dav-test/testdatei.txt
=> Daß die Datei noch nicht vorhanden ist stimmt ja, aber warum erfolgt der Zugriff mit dem lokalen Benutzernamen?

Ein Lesezugriff:
84.179.171.227 - rico [20/Jun/2010:14:39:13 +0200] "GET /dav-test/dir1/License.txt HTTP/1.1" 200 2355 "-" "Microsoft Data Access Internet Publishing Provider DAV"

=> testweise wurde der lokale Benutzer (rico) mit einem abweichenden Passwort auf dem Server angelegt.
[Sun Jun 20 13:22:41 2010] [error] [client 84.179.171.227] Digest: user rico: password mismatch: /dav-test/testdatei.txt
=> und damit die ungefragte Verwendung der lokalen Daten bestätigt.

=> Synchronisation beider Passwörter:
[Sun Jun 20 13:23:37 2010] [error] [client 84.179.171.227] File does not exist: /srv/dav/test/testdatei.txt
[Sun Jun 20 13:23:37 2010] [error] [client 84.179.171.227] access to /dav-test/testdatei.txt failed, reason: user 'rico' does not meet 'require'ments for user/valid-user to be allowed access
=> 'rico' ist zwar jetzt 'valid-user', bekommt damit aber keinen Schreibzugriff.

Anpassung der Serverkonfig (lokaler Benutzer ergänzt):
<LimitExcept OPTIONS>
Require user testuser rico
</LimitExcept>

Es erscheint zwar noch eine Fehlermeldung, aber die Datei wurde geschrieben. 
error.log:
[Sun Jun 20 14:21:57 2010] [error] [client 84.179.171.227] File does not exist: /srv/dav/test/testdatei.txt
access.log:
84.179.171.227 - rico [20/Jun/2010:14:21:57 +0200] "HEAD /srv/dav/test/testdatei.txt HTTP/1.1" 401 - "-" "Microsoft Data Access Internet Publishing Provider DAV"
84.179.171.227 - rico [20/Jun/2010:14:21:57 +0200] "HEAD /srv/dav/test/testdatei.txt HTTP/1.1" 404 - "-" "Microsoft Data Access Internet Publishing Provider DAV"
84.179.171.227 - rico [20/Jun/2010:14:21:57 +0200] "PUT /srv/dav/test/testdatei.txt HTTP/1.1" 201 348 "-" "Microsoft Data Access Internet Publishing Provider DAV"

@@ Zeile 1: / Zeile 1: @@
-==WebDAV==
+=WebDAV=
-===ServerConfig (apache2)===
+==Server==
 In der Konfiguration des SSL-VirtHosts des apache sind folgende Einstellungen einzutragen:
@@ Zeile 37: / Zeile 39: @@
 Die Relevanz der 'AuthDigestDomain'-Angabe wurde noch nicht geprüft.
-===XP-Clients===
+==Clients==
 Diverse Anleitungen treffen unterschiedliche Aussagen bzgl. der Umsetzung. Sicher ist jedoch, daß MS wieder mal den Standard nicht einhält. Während unter Linux bzw. mit einem DAVClient unter Windows (z.B. DAVExplorer) bereits alles funktioniert, ist Windows noch nicht mal in der Lage den Ordner zu finden.
@@ Zeile 103: / Zeile 109: @@
 Unter Umständen können die Applikationen trotzdem nicht darauf zugreifen. Dazu gehört auch das JTL-WAWI. Nach dem Zugriff zum speichern der XML-Datei via Netzwerkumgebung auf den konfigurierten WebOrdner erfolgt ein erneutes Login auf dem DAV-Server. Nach dem Login kann aber das Zielverzeichnis nicht gelesen werden, es werden keine vorhandenen Dateien oder Ordner angezeigt. Laut Logfile erfolgt diesbezüglich auch keine Anfrage beim Server. Das Abspeichern einer Datei schlägt fehl.
-===Vista-Clients===
+===Vista===
 laut der Anleitung von Arne Schirmacher http://www.schirmacher.de/display/INFO/Mit+WebDAV+Verzeichnis+verbinden kann Vista anscheinend im Gegensatz zu XP der Ressource zwar Laufwerksbuchstaben zuordnen, aber andererseits nicht per SSL auf den DAV-Server zugreifen. Zu beachten ist ebenfalls der eigenartige Ablauf bei der Eingabe der Logindaten.

← Nächstältere Version		Version vom 20. Juni 2010, 13:40 Uhr
Zeile 102:		Zeile 102:
	WebOrdner sind jedoch nicht grundsätzlich als systemweite Ressourcen zu betrachten. D.h. man kann zwar per Windows-Explorer darauf ohne (erneute) Passwortabfrage darauf zugreifen, das ist aber nicht gleichzeitig für die anderen Applikationen gültig.		WebOrdner sind jedoch nicht grundsätzlich als systemweite Ressourcen zu betrachten. D.h. man kann zwar per Windows-Explorer darauf ohne (erneute) Passwortabfrage darauf zugreifen, das ist aber nicht gleichzeitig für die anderen Applikationen gültig.
	Unter Umständen können die Applikationen trotzdem nicht darauf zugreifen. Dazu gehört auch das JTL-WAWI. Nach dem Zugriff zum speichern der XML-Datei via Netzwerkumgebung auf den konfigurierten WebOrdner erfolgt ein erneutes Login auf dem DAV-Server. Nach dem Login kann aber das Zielverzeichnis nicht gelesen werden, es werden keine vorhandenen Dateien oder Ordner angezeigt. Laut Logfile erfolgt diesbezüglich auch keine Anfrage beim Server. Das Abspeichern einer Datei schlägt fehl.		Unter Umständen können die Applikationen trotzdem nicht darauf zugreifen. Dazu gehört auch das JTL-WAWI. Nach dem Zugriff zum speichern der XML-Datei via Netzwerkumgebung auf den konfigurierten WebOrdner erfolgt ein erneutes Login auf dem DAV-Server. Nach dem Login kann aber das Zielverzeichnis nicht gelesen werden, es werden keine vorhandenen Dateien oder Ordner angezeigt. Laut Logfile erfolgt diesbezüglich auch keine Anfrage beim Server. Das Abspeichern einer Datei schlägt fehl.
		+
		+	===Vista-Clients===
		+
		+	laut der Anleitung von Arne Schirmacher http://www.schirmacher.de/display/INFO/Mit+WebDAV+Verzeichnis+verbinden kann Vista anscheinend im Gegensatz zu XP der Ressource zwar Laufwerksbuchstaben zuordnen, aber andererseits nicht per SSL auf den DAV-Server zugreifen. Zu beachten ist ebenfalls der eigenartige Ablauf bei der Eingabe der Logindaten.

← Nächstältere Version		Version vom 20. Juni 2010, 13:28 Uhr
Zeile 99:		Zeile 99:
	84.179.171.227 - rico [20/Jun/2010:14:21:57 +0200] "HEAD /srv/dav/test/testdatei.txt HTTP/1.1" 404 - "-" "Microsoft Data Access Internet Publishing Provider DAV"		84.179.171.227 - rico [20/Jun/2010:14:21:57 +0200] "HEAD /srv/dav/test/testdatei.txt HTTP/1.1" 404 - "-" "Microsoft Data Access Internet Publishing Provider DAV"
	84.179.171.227 - rico [20/Jun/2010:14:21:57 +0200] "PUT /srv/dav/test/testdatei.txt HTTP/1.1" 201 348 "-" "Microsoft Data Access Internet Publishing Provider DAV"		84.179.171.227 - rico [20/Jun/2010:14:21:57 +0200] "PUT /srv/dav/test/testdatei.txt HTTP/1.1" 201 348 "-" "Microsoft Data Access Internet Publishing Provider DAV"
		+
		+	WebOrdner sind jedoch nicht grundsätzlich als systemweite Ressourcen zu betrachten. D.h. man kann zwar per Windows-Explorer darauf ohne (erneute) Passwortabfrage darauf zugreifen, das ist aber nicht gleichzeitig für die anderen Applikationen gültig.
		+	Unter Umständen können die Applikationen trotzdem nicht darauf zugreifen. Dazu gehört auch das JTL-WAWI. Nach dem Zugriff zum speichern der XML-Datei via Netzwerkumgebung auf den konfigurierten WebOrdner erfolgt ein erneutes Login auf dem DAV-Server. Nach dem Login kann aber das Zielverzeichnis nicht gelesen werden, es werden keine vorhandenen Dateien oder Ordner angezeigt. Laut Logfile erfolgt diesbezüglich auch keine Anfrage beim Server. Das Abspeichern einer Datei schlägt fehl.

@@ Zeile 47: / Zeile 47: @@
 In beiden Fällen kommt man zum "Assistenten zum Hinzufügen von Netzwerkressourcen".
--> Weiter -> (andere Netzwerkressource) Weiter -> https://<HOSTNAME>/<WebDAV-Ordner> (z.B. https://ssl.bamsenet.de/dav-test)<br />
+-> Weiter -> (andere Netzwerkressource) Weiter ->  https://ssl.bamsenet.de/dav-test<br />
 Falls nicht alle Workarounds für Windows in der ServerConfig vorhanden sind, erkennt Windows den DAV-Ordner hier nicht.

@@ Zeile 86: / Zeile 86: @@
 => testweise wurde der lokale Benutzer (rico) mit einem abweichenden Passwort auf dem Server angelegt.
    [Sun Jun 20 13:22:41 2010] [error] [client 84.179.171.227] Digest: user rico: password mismatch: /dav-test/testdatei.txt
-=> und damit die ungefragte Verwendung der lokalen Daten bestätigt.
+=> und damit die ungefragte Verwendung der lokalen Anmeldedaten bestätigt.
 => Synchronisation beider Passwörter:

@@ Zeile 51: / Zeile 51: @@
 access.log im Erfolgsfall:
-.179.171.227 - - [20/Jun/2010:14:28:45 +0200] "PROPFIND /aronia-jtl HTTP/1.1" 401 555 "-" "Microsoft Data Access Internet Publishing Provider DAV"
+.179.171.227 - - [20/Jun/2010:14:28:45 +0200] "PROPFIND /dav-test HTTP/1.1" 401 555 "-" "Microsoft Data Access Internet Publishing Provider DAV"
 Im Erfolgsfall wird der Benutzername (testuser) und das Passwort für die Ressource abgefragt, mit dem darauf zugegriffen werden soll. Passwort merken wurde dabei ebenfalls markiert. Serverseitig muß hierfür "AuthType Digest" konfiguriert sein oder in der Registry BasicAuth freigeschaltet werden. Digest ist hier allerdings die bevorzugte Variante.

WebDAV - Versionsgeschichte

Netbreaker: /* XP */

Netbreaker am 20. Juni 2010 um 14:31 Uhr

Netbreaker: /* XP-Clients */

Netbreaker: /* XP-Clients */

Netbreaker: /* XP-Clients */

Netbreaker: /* XP-Clients */

Netbreaker: Die Seite wurde neu angelegt: ==WebDAV== ===ServerConfig (apache2)=== In der Konfiguration des SSL-VirtHosts des apache sind folgende Einstellungen einzutragen: ...

Netbreaker: Die Seite wurde neu angelegt: ==WebDAV== ===ServerConfig (apache2)=== In der Konfiguration des SSL-VirtHosts des apache sind folgende Einstellungen einzutragen:
...