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.
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.
