webdav und .htaccess

[testdemo]

Hallo zusammen,

ich möchte mit WebDAV auf meine Documentroot vom apache zugreifen das funktioniert auch soweit! Leider scheint WebDAV jedoch .htaccess Dateien nicht zu ignorieren also benutzt diese auch bei WebDAV Zugriff.

Wie kann ich WebDAV dazu bringen diese nicht auszuwerten wenn ich per WebDAV auf meine Documentroot zugreife ?


Gruß
Dennis

[Roger Wilco]

Schau dir die Direktive AllowOverride an. Wenn du die .htaccess nur umbenennen willst, dann auch AccessFilename.

[flo]

Ich denke eehr, daß Limit hier angebracht wäre - ich glaube, er möchte verhindern, daß die Dateien per DAV verändert werden können.

flo.

[kawfy]

@flo: ich kann zwar nicht testdemos Gedanken lesen, aber: WebDAV ist doch dafür da, die Dateien des Webspaces einfach zum Bearbeiten bereit zu stellen. Die .htaccess-Dateien tragen wahrscheinlich WWW-Authenticate-Infos ("Verzeichnisschutz") und dann poppt bem WebDAV-Zugriff immer ein Fenster auf bzw. der Zugriff ist nicht möglich, weil der WebDAV-Client keine Zugangsdaten liefern will.

[geo]

Die Authentifizierung für dav sollte besser in einer Location Direktive stehen, z.B.

Code: Select all

<Location "/mydav">
DAV On
AuthType Basic
AuthName "DAV"
AuthUserFile  /var/dav/pass/pass.word
AuthGroupFile /dev/null
Require user xyz
</Location>

(Limit Direktive ggf. Ergänzen)

Die Passwortdatei wie üblich erstellen mit

Code: Select all

htpasswd -c /var/dav/pass/pass.word

[testdemo]

ich will die .htaccess per webdav verändern können geht das nicht ?
Da ich statt ftp nur noch webdav für die pflege meiner sites nutzen will möchte ich den webmastern zugriff geben und zwar vollen (also sie sollen auch die .htaccess dateien ändern können über webdav)

[Joe User]

Auch wenn ich Deinen Wunsch nach einer völlig kaputten und durchsiebten, sprich unsicheren/offenen, Konfiguration nicht nachvollziehen kann:
Du suchst folgenden Part Deiner httpd.conf:

Code: Select all

<Files ~ "^.ht">
    Order allow,deny
    Deny from all
</Files>

[flo]

Das ist ganz großer Mist - wenn Du die .htaccess-Dateien wirklich bearbeiten lassen möchtest, leg einen zweiten vhost mit der gleichen root an auf dem sich Deine Kumpels/Kunden dann einloggen.

Nicht nur, daß die Bearbeitung von PHP-Daten unmöglich sein wird, sondern die .htaccess-Dateien sind damit für alle erst einmal lesbar.

Außerdem kriege ich ab und zu in meinem Logfile mit, daß inzwischen wohl auch automatisierte Zugriffe auf DAV-Server erfolgen.

Grüße,

flo.

[testdemo]

Moin,
um gotteswillen den Part will ich auf keinen Fall rausnehmmen

Code: Select all

<Files ~ "^.ht"> 
    Order allow,deny 
    Deny from all 
</Files> 

wer ja fatal.
Ich will doch nur webdav zum pflegen der Sites benutzen statt FTP!
Ist das nicht möglich ?


gruß Dennis

[flo]

hi Dennis,

Ich will doch nur webdav zum pflegen der Sites benutzen statt FTP!
Ist das nicht möglich ?

möglich ist das schon, aber willst Du eine Site wirklich komplett - inkl. cgi/php/htaccess usw. per http pflegen, mußt Du den ganzen Kram ausschalten und kriegst dann Schwierigkeiten mit aufwändigeren Projekten.

Htaccess hatten wir schon ... bei CGIs kriegst Du halt, wenn per apache als cgi abgerufen, nur den Output und nicht das script.

Davon abgesehen unterstützt DAV soweit ich weiß auch keine Zugriffsrechte, d.h. chmod kannst Du dann auch vergessen.

Und - weiterer Nachteil - nachdem die Dateien ja vom Webserver geschrieben werden und dieser wohl meistens als Apache-User laufen wird, kriegst Du spätestens dann Probleme, wenn Du die Seite dann mal wieder als "normaler" User per FTP ändern mußt.

Die Lösung mit dem separaten vhost auf anderem Namen oder anderem Port wäre hier noch das beste. Vorteil daran - der Enduser und das Betriebssystem können ansehen und editieren/mounten/ändern noch unterscheiden.

Gerade bei möglichen Schreibzugriffen gehört jegliche Form der .htaccess-Bearbeitung abgeschalten, wenn es sich nicht um einen absolut vertrauenswürdigen Userkreis handelt. Du kannst unter Umständen damit den kompletten Passwortschutz aushebeln.

Grüße,

flo.

P.S.: Nehme WebDAV nun seit fast zwei Jahren per Apache2 und bin eigentlich begeistert :-)

[Joe User]

Bis auf die .ht* kannst Du doch alle Dateien per WebDav bearbeiten, oder habe ich etwas überlesen? Und an die .ht* kommst Du (und jeder Andere) nur durch das Entfernen besagter Direktive ran...

[Roger Wilco]

Und an die .ht* kommst Du (und jeder Andere) nur durch das Entfernen besagter Direktive ran...

Was spricht dagegen, einfach folgende Direktive in einen <Directory>-Abschnitt für das betreffende Verzeichnis zu packen?

Code: Select all

<Files ~ "^.ht">
    Order allow,deny
    Allow from all
</Files>

[Joe User]

Was spricht dagegen, einfach folgende Direktive in einen <Directory>-Abschnitt für das betreffende Verzeichnis zu packen?

Folgendes:

an die .ht* kommst Du (und jeder Andere)

[Roger Wilco]

Folgendes:

an die .ht* kommst Du (und jeder Andere)

Ich hatte dabei zumindest eine vorherige Authentifizierung angenommen. Wäre ja auch sinnlos, wenn jeder Hinz & Kunz (per WebDAV) darauf zugreifen können. Der Zugriff per WebDAV sollte in erster Linie dem Ersatz von FTP dienen.

[testdemo]

ok vielen Dank an euch alle ! WebDAV ist wohl definitiv nicht geeignet für die Pflege von Websites - was ich mich jedoch frage warum dann SVN auf WEBDAV baut ?


gruß Dennis

[Roger Wilco]

WebDAV ist wohl definitiv nicht geeignet für die Pflege von Websites

Das würde ich so nicht sagen. Wenn der Webserver richtig konfiguriert ist und SSL verwendet wird (-> WebDAVS), würde ich WebDAV durchaus als Alternative zu FTP(s) oder SCP/SFTP ansehen.

[flo]

was ich mich jedoch frage warum dann SVN auf WEBDAV baut ?
gruß Dennis

Weil Du die meisten Probleme (im Vergleich zu Webhosting) dann nciht hast - ein SVN-Repository funktioniert, wenn alle SVN-Funktionen angeboten werden und diese auch per Client verstanden werden, mehr muß das Ding ja nicht können ...

WebDAV als HTTP-Erweiterung ist sinnvoll, aber halt nicht für alles zu gebrauchen, wenn man nicht entweder mit gewissen Einschränkungen leben möchte oder aber bereit ist, diese mit Konfigurationsaufwand zu umgehen.

Ich arbeite hier per DAV auf Port 8080 und kann damit jede Datei bearbeiten, die ich möchte, sogar CGIs. Testen kann ich das ganze aber funktionsfähig auf Port 80. Hat mit PHP natürlich auch den Vorteil, daß keine Konflikte mit Datei-/Benutzerrechten auftreten können, weil nur der User "www-data" in das Verzeichnis schreibt.

Grüße,

flo.

[testdemo]

WebDAV scheint ziemlich ungeeignet zu sein um mit Windows Clients zu interargieren.
http://greenbytes.de/tech/webdav/webfol ... -list.html
http://www.atarex.com/services/support/ ... msft.shtml

So wie ich das sehe scheint ja nur SVN oder SCPonly die Lösung zu sein? Wobei SVN selbst doch gar nicht verschlüsselt ist oder habe ich das falsch verstanden ?


Gruß Dennis

[flo]

Hi,

WebDAV scheint ziemlich ungeeignet zu sein um mit Windows Clients zu interargieren.

Jein ... wenn ich mal auf meiner Windowskiste unterwegs bin (WinXP Pro) habe ich keine Probleme damit, habe aber auch den Registry-Fix drauf, der ein Problem mit Passwörtern beseitigt - ist aber schon länger her.

Nachdem man unter Windows eh FTP und DAV mounten kann, ist es mir relativ egal, was ich nehme, aber bei Webseiten und anderen Inhalten, die auch über den Apache ausgeliefert werden oder Sachen, die Samba-Problematiken mit sich bringen könnten, nehme ich HTTP zum Arbeiten - damit ist es auch relativ egal, wo der jeweilige Rechner steht, das Protokoll ist halt leichter (und sicherer) zu tunneln als SMB.

SVN für jeden Kunden einzeln aufzusetzen, halte ich für übertrieben, und SCPonly ist (IMHO) für die Masse zu kompliziert. DAV und FTP sind halt inzwischen auf jedem System standardmäßig unterstützt, und sei es nur lesend, das kann jeder Browser.

Ach ja - noch ein Grund, warum ich DAV einsetze - bin Mac-User und liebe mein iBook und den iMac meiner Frau. ;-)


Grüße,

flo.

[Roger Wilco]

und SCPonly ist (IMHO) für die Masse zu kompliziert.

Finde ich nicht. Mittlerweile unterstützen die meisten verbreiteten FTP-Clients auch die Ã?bertragung per SFTP oder SCP, so dass die Benutzung dieses Protokolls für den Benutzer nicht wirklich komplizierter ist. Im besten Fall begrenzt sich die Umstellung auf das setzen eines Häkchens oder die Auswahl in einer Combobox...