Hallo Zusammen Ich habe *.s.abrecht.li so eingerichtet, das das auf meinen Webserver zeigt. Momentan bekomme ich WebDAV und Login unter *-dav.s.abrecht.li. * kann da wirklich alles sein, gibt es den Namen nicht, und ich logge mich ein, lege ich den Ordner mit einem Script an. Und jede Nacht lösche ich die leeren Verzeichnisse wieder weg. Unter *-s.s.abrecht.li. kann ich dann auf normal als Webseite auf das zeug zugreifen. Jetzt finde ich es aber unpraktisch, jedes mal das "-s." mit "-dav." ersetzen zu müssen. Das Problem ist halt, als normaler Webserver muss PHP und so laufen, und soll keine Anmeldung erforderlich sein. Aber für WebDAV soll eine Anmeldung erforderlich sein, und der Dateiinhalt beim GET usw. muss unverändert bleiben. Ich muss also irgendwie weiterhin zwischen WebDAV client und normalem WebBrowser unterscheiden. Wie mache ich das am besten? Es scheint ja keinen Header oder so zu geben, auf den ich mich verlassen kann? Wie würdet ihr das machen? Im Anhang ist noch meine momentane Apache config.
IMO geht das prinzipbedingt nicht. WebDAV ist eine Erweiterung von HTTP, nutzt aber stellenweise eben auch die normalen HTTP-Methoden (GET, POST...). Der Login ist da nicht das Hauptproblem. Du könntest höchstens in PHP einen WebDAV-Server implementieren der die DAV-Methoden eben erst nach Login akzeptiert, aber das ist viel Aufwand. Mit Apache alleine geht das ziemlich sicher nicht vernünftig.
Die Apache Konfiguration anzupassen ist für mich kein Problem, das kriege ich hin. Ob ich jetzt einen Header checke oder die URL oder sonst was ist kein grosser Unterschied. Aber solange ich nicht unterscheiden kann, ob das jetzt ein Browser oder ein WebDav Client ist, nützt mir das alles nichts. Ein eigener WebDAV-Server zu implementieren wird mich nicht weiter bringen, dadurch würde sich ja nichts an meinem Problem ändern. Nach dem Login könnte ich wohl einfach checken, ob der User eingeloggt ist. Aber davor muss ich ja entscheiden, ob ich ein HTTP 401 sende, um den Login zu initiieren, oder nicht. Vielleicht reicht es ja, wenn ich bei WebDav spezifischen Methoden (z.B. PROPFIND) ein Login voraussetze? Muss ich mal ausprobieren. DAV: Header könnte ich auch noch checken aber der wird vom Client nur mitgegeben, wenn nötig. Muss ich mal ausprobieren.
🐧 DPA 🐧 schrieb: > Ob ich jetzt einen Header checke oder die URL oder sonst > was ist kein grosser Unterschied. Aber solange ich nicht unterscheiden > kann, ob das jetzt ein Browser oder ein WebDav Client ist, nützt mir das > alles nichts. Ein Browser ist halt automatisch auch ein WebDAV-Client und umgekehrt. Nur dass der WebDAV Client noch etwas mehr kann. Ein einfaches "GET" kann halt auch vom WebDAV-Client kommen. Und einen Header zur Unterscheidung gibt's nicht. 🐧 DPA 🐧 schrieb: > Vielleicht reicht es ja, wenn ich bei WebDav spezifischen Methoden (z.B. > PROPFIND) ein Login voraussetze? Das ginge wohl, aber wie machst du das mit POST? Das ist auch eine normale HTTP-Methode. Allerdings würde die natürlich kein normaler Websiten-Besucher durchführen und wenn, würdest du es eh nicht erlauben wollen. Wäre wohl ein pragmatischer Ansatz.
Falls der Client erst ein PROPFIND oder so macht, kann ich das login an der Stelle machen. Naja, lass ich das *-dav. einfach zusätzlich zum *-s, als Fallback. Dann müsste ich es mit *-s. normal im Dateimanager mounten können, und normal darauf arbeiten können, und das *-dav. könnte man immer noch nehmen, wenn man nicht zu faul ist das anzupassen oder die Anwendung das braucht direkt GET POST macht. Als Faulheit hack müsste es ausreichen. Mal sehen. Sobald der Client mal angemeldet ist ist es ja trivial.
Ich hab es jetzt mehr oder weniger am laufen, aber es ist noch nicht ganz so, wie es sein sollte. Aus irgend einem grund hat der OPTIONS request für / bei *-s. eine 404 zurückgegeben, das hat die WebDav clients verwirrt. Jetzt hab ich das zusammen mit PROPFIND usw. zur Spezialconfog für die WebDav und spezifischen Methoden dazugetan. Liefert jetzt 401 zurück. Ist zwar eigentlich falsch, OPTIONS sollte eigentlich immer 200 + die erlaubten WebDav Methoden zurückgeben. Muss ich mal noch schauen. Und eigentlich wollte ich checken ob der User mit einem WebDav User angemeldet ist oder nicht, aber momentan checke ich nur ob der Authorization gesetzt ist, und checke danach ob die Anmeldedaten stimmen. Das ist nicht ideal, weil ich mir die Möglichkeit basic Auth in nem PHP script oder so zu nutzen eigentlich lassen wollte. Bei z.B. NTLM Authorization könnte man sowas natürlich nicht machen, aber bei Basic ode Kerberos ist sowas eigentlich kein Problem. Ich kann es in Apache nur nicht konfigurieren. Wenn ich kein "require valid user" mache setzt er die REMOTE_USER auch wenn der nicht gültig ist, wenn ich "require valid user" setze gibts ohne und bei ungültigem login natürlich ein 401, ist beides nicht was ich bräuchte. Und dann kann ich die REMOTE_USER auch nicht da checken wo ich sie bräuchte, da die Reihenfolge in welche die dinge in Apache ausgewertet ist da nicht mit macht. So ein scheiss. Ein paar andere Sachen sind auch unschön. z.B. die RewriteRule am Ende die alles intern ins richtige Verzeichnis leitet. Da würde ich eigentlich lieber das DocumentRoot dynamisch setzen, geht so aber auch nicht. Vielleicht mache ich den ganzen scheiss mal nochmal neu. Ich glaube ich mache mir eine Art eigenen Load Balancer, der den Login Part übernimmt, und einen Header setzt. Und dann könnte ich das auch gleich ganze Container mit Webservern usw. starten lassen statt alles vom selben Apache verwalten zu lassen. Auf dem Server ist auch viel Altkram von den letzten paar Jahren, den ich auch mal aufräumen & vereinheitlichen sollte, das kann ich dann auch gleich noch machen. Eventuell sollte ich auch mal Kerberos einführen, einfach eine Domain im Dateibrowser öffnen zu können und man hat ne neue Sandbox für ne Webseite ist cool, aber jedes mal die Login daten eingeben wird da langsam unpraktisch. Dann könnte ich auch die internen Services die von aussen nicht erreichbar sind mal auch intern richtig absichern.
Nutz doch einen anderen Port. Webseite wie gewöhnlich auf 80/443 und WebDAV auf 81.
Was ist eigentlich genau das Ziel dieser Übung? Unterschiedliche Dienste (HTTP, DAV) über unterschiedliche Subdomains oder Pfade laufen zu lassen, ist doch überall anerkannte Praxis. Außerdem aus Sicherheitsgründen sehr sinnvoll, praktisch für Monitoring, Accounting usw. Über DAV direkt live an der Website arbeiten ist absolut nicht mehr Stand der Technik, meiner Meinung nach auch mit guten Gründen. "Üblich" ist inzwischen, dass man die Seite in die Versionsverwaltung eincheckt und dann ein geprüftes lauffähiges Release auf dem Webserver ausgepackt und bereit gestellt wird. Dann kann auch nicht jeder mit DAV Login (oder geklauter Session) seine Malware & Spam Seiten auf deinem Server ablegen.
Andre schrieb: > Was ist eigentlich genau das Ziel dieser Übung? Grösstenteils Bequemlichkeit. Kommt immer mal wieder vor, dass ich da schnell mal was ausprobiere, oder eine kleine temporäre Anwendung mache die ich 1 2 mal für was anderes brauche, oder einfach mal schnell ein paar Dateien da drauf schiebe. Und dann muss ich mich jedes mal daran erinnern, das ich da an der URL anpassen muss. Eigentlich bin ich der einzige mit den Zugangsdaten. Das sind so Sachen, wie z.B. kleine Tools: * Ein QR-Code Reader Bookmarklet: https://qr-s.s.abrecht.li/ * Was zum Linien als CSS Background mittels Gradienten zu zeichnen (unterstützt CSS Variablen und solches zeug): https://bgl-s.s.abrecht.li/ https://bgl-s.s.abrecht.li/index.php/rajy4w.1/9 Spielereien: * https://anytwo-s.s.abrecht.li/#Good%20Code&Fast&Cheap * https://tic-tac-toe-s.s.abrecht.li/ * Irgendwelche Screenshots und Dateien, die ich irgendwo Poste / Share (z.B. auf IRC): https://temp-s.s.abrecht.li/ Solchen Kram halt. Ist echt praktisch da einfach mal schnell was drauf schieben zu können. Eine Besonderheit ist noch, dass ich immer eine beliebige Subdomain erfinden kann. Gerade da das kleine schnelle Experimente sind, ist das Sicherheitstechnisch wichtig. Falls eine Anwendung mal eine XSS Lücke haben sollte, kann da nicht viel passieren. Die CSP stellt sicher, dass keine Requests sonst wohin gemacht werden können. Aber ein Angreifer könnte dann immer noch sachen machen, wie z.B. einen Service Worker einrichten, und alles unter der selben Domain abfangen. Durch unterschiedliche Subdomain kann ich mich vor solchen Sachen schützen. Klar, das hilft nur Clientseitig, ist nicht perfekt. Aber zum herum experimentieren besser als nichts, gerade auch, wenn es was ist, was fremden JS code (npm usw.) enthält. Andre schrieb: > "Üblich" ist inzwischen, dass man die Seite in die Versionsverwaltung > eincheckt und dann ein geprüftes lauffähiges Release auf dem Webserver > ausgepackt und bereit gestellt wird. Ja, solches zeug habe ich auch. Das ist gut für richtige Projekte. Ist aber nicht so praktisch, wenn ich schnell mal so was kleines irgendwo hin packen will.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.