HTML Online FTP Client

[Daaron]

Aus der eher jüngeren Vergangenheit sei zum Beispiel dies erwähnt:
http://www.heise.de/security/meldun...-gefaehrden-SSL-Verschluesselung-1925115.html

Das betrifft dann aber analog auch SFTP, SCP, HTTPS und SSH im Allgemeinen... Also worauf willst du hinaus? TLS ist besser als nichts. TLS ist das einzige, was wir haben. Also nutzt man TLS.

Interessanterweise ist das beste Mittel gegen den im Artikel angesprochenen Kram, einfach auf Snakeoil zu setzen.

Warum haltet ihr denn alle an FTP fest? So wie ich das verstanden habe, ist FTP doch vollkommen überflüssig. Man befindet sich doch eh schon auf der Homepage, da reicht ein simples Dateiverwaltungstool mit Userunterstützung und gut ist.

WebFTP schon mal gehört? Schon mal mit Tools Verwaltungsschnittstellen wie Confixx gearbeitet, die WebFTP anbieten? Hier macht es einen GEWALTIGEN Unterschied, ob man einfach mit PHP die Dateien erstellt, oder ob man eine FTP-Verbindung aufbaut.

Die Verwaltungsschnittstelle läuft im Zweifel als www-data oder einem spezifischen User für dieses Frontend. Sie liegt im Zweifel irgendwo in /usr/share/... oder sowas.... und das eben noch nicht einmal unbedingt auf der selben Maschine, auf der deine Zielwebseite liegt.
Deine Webseiten, selbst wenn sie auf dem selben Host wie deine Verwaltung liegen, gehören aber nicht www-data (außer du bist ein Vollidiot). Sie gehören meinetwegen web123:client45. www-data hat schon erstmal gar keine Lese-, geschweige denn Schreibrechte für den Ordner von web123. Und selbst wenn www-data schreiben könnte, er würde im Zweifel als www-data schreiben. Der lesende Apache-Prozess gehört dann aber web123 und kann Dateien von www-data im Zweifel nicht lesen... außer der Admin ist ein Idiot.

FTP hingegen ist es egal, ob du auf Localhost bleibst oder nicht. FTP hat durch die Credentials direkt die korrekten Berechtigungen.

 

[asdfman]

SSH arbeitet nicht mit Zertifikaten, also ist es dadurch nicht betroffen.

 

[Yuuri]

@ Daaron: Klar, FTP und alles ist mir bekannt. Nur frage ich mich, wieso wegen ein paar Dateiuploads ein Weg mit 20 Umwegen gegangen wird.

Datei hochschieben (per HTTP/Ajax/...), User mit angeben, fertig. Ein Cron kann dann alle Jubelminuten die fertig hochgeladenen Dateien woanders hinverfrachten, wenn man denn will. Wieso denn aufwändig ein Frontend über HTTP(S) für (S)FTP(S) anbieten, was auch im Windows Explorer problemlos eingebunden werden könnte?

 

[Daaron]

Nun, die einfachste Antwort lautet: Weil der Kunde WebFTP will?

Und die Idee mit dem Cronjob... da seh ich ein paar Pferdefüße. Da wäre z.B. erstmal die Verzögerung. Und dann hast du immer noch das Problem, dass www-data, der dein Controlpanel betreibt, nicht aus dem Ordner von web123 lesen kann -> www-data kann dem User keine Ordnerstruktur anzeigen, geschweige denn navigieren. Oh, außer du baust einen Cronjob, der die Ordnerstruktur in irgend einer Form, z.B. als VFS in SQL, nachbaut... Sehr performant, sehr unaufwändig...

 

[Yuuri]

Nun, die einfachste Antwort lautet: Weil der Kunde WebFTP will?

Der Kunde will auch einen 486er, wenn er noch keinen i5 kennt. Würdest du es ihm trotzdem so verkaufen, ohne ihm Alternativen aufzuzeigen?

Die einzige Anforderung, die ich herausgelesen habe, war nun mal "will Dateien hochladen können". Die Sache mit dem FTP war wohl die Idee des TE, die er gleich mit eingebracht hat.

Hier könnte man also ein kleines Uploadscript mit User-/Passworteingabe (vielleicht gleich per .htpasswd?) dranhängen (evtl. mit einem Ajax-Uploader, HTML5, Drag'n'Drop, im Chrome einfach den Ordner reinziehen etc.) und hat ohne großen Aufwand eine schnelle Lösung an zentraler Stelle und ohne viele Abhängigkeiten ohne große Umwege gehen zu müssen.

Aber nun gut, ich hab ja nur ne Alternative aufzeigen wollen...

Und die Idee mit dem Cronjob... da seh ich ein paar Pferdefüße. Da wäre z.B. erstmal die Verzögerung.

... von fünf Minuten? Hochgeladen wird in /tmp, dann nach .../user/done verschoben und der Cron kann dann von mir aus alles nach /home/kunden/sowieso verschieben, sodass sie vom HTTP getrennt liegen. Der Cron kann auch fix als Bashscript hinterlegt werden, muss überhaupt höhere Scriptsprache zur Anwendung kommen. Wie die Daten dann vom Backend/der Firma aus abgerufen werden, steht hier doch nicht zur Debatte bzw. erst später.

Und dann hast du immer noch das Problem, dass www-data, der dein Controlpanel betreibt, nicht aus dem Ordner von web123 lesen kann -> www-data kann dem User keine Ordnerstruktur anzeigen, geschweige denn navigieren.

Das war doch auch nicht der Anspruch? Ich lese hier immer nur "soll Dateien hochladen können". Nichts von "anzeigen", "löschen", "navigieren", "Ordner" oder sonstiges. Ergo ein stink normales Frontend, um Arbeit/Material A von Firma B zu Firma X transferieren zu können, ohne irgendwas großes einrichten zu müssen.

Oh, außer du baust einen Cronjob, der die Ordnerstruktur in irgend einer Form, z.B. als VFS in SQL, nachbaut... Sehr performant, sehr unaufwändig...

Datenbankgestütz muss hier gar nichts laufen.

 

[Daaron]

Das war doch auch nicht der Anspruch? Ich lese hier immer nur "soll Dateien hochladen können". Nichts von "anzeigen", "löschen", "navigieren", "Ordner" oder sonstiges. Ergo ein stink normales Frontend, um Arbeit/Material A von Firma B zu Firma X transferieren zu können, ohne irgendwas großes einrichten zu müssen.

Ich blieb hier innerhalb meines Gedankenspiels vom WebFTP für Control Panel oder ähnliches. Und dazu gehört eben auch, die Ziel-Ordnerstruktur anzeigen zu können. FTP kann eben deutlich mehr als ein POST-Request.