File Upload und Sicherheit
heinetz
0 dedlfix
0 
Matthias Apsel
0 heinetz
0 heinetz
File Upload und Sicherheit
heinetz
Matthias Scharwies
MudGuardHallo Forum,
ich stehe vor der Aufgabe, auf einer Website einen File-Upload einzubauen. Das würde ich mit einem jQuery-Plugin umsetzen. Vorab möchte ich mich mit dem Thema Sicherheit/Datenschutz in diesem Kontext auseinandersetzen.
-
Könnt Ihr mir Tipps geben, was ich beachten muss?
-
Wie muss ich mir "cross domain file upload" vorstellen?
Please note that all provided implementations allow cross-site file uploads. If you don't need that functionality, you should remove the code parts that set the "Access-Control-Allow" headers.
Beim klassischen Upload über input type="file" werden Files per http vom lokalen FS des Users in ein dafür vorgesehenes Verzeichnis a.d. Webserver kopiert. Muss ich mir unter cross domain vorstellen, dass die von User hochgeladene Datei auf einem anderen Webserver gespeichert werden kann als der, auf dem das Upload-Form aufgerufen wird?
danke für Tipps und
beste gruesse, heinetz
-
Tach!
Vorab möchte ich mich mit dem Thema Sicherheit/Datenschutz in diesem Kontext auseinandersetzen.
- Könnt Ihr mir Tipps geben, was ich beachten muss?
Das Upload-Verzeichnis sollte außerhalb des DocumentRoot liegen, damit nicht jemand Zeugs hochlädt und gleich vom Webserver ausführen lassen kann. Sollte das heutzutage immer noch nicht seitens des Providers gehen, so ist ein Wechsel dringend angeraten.
Sollen die Dateien sofort zum Download zur Verfügung stehen und du keine händische Prüfung vornehmen möchtest, ist zumindest eine Dateiendungsprüfung vorzunehmen und nur ein paar harmlose Endungen sollten gestattet werden.
- Wie muss ich mir "cross domain file upload" vorstellen?
Das Script mit dem File-Upload-Formular (oder deinem Javascript-Aufsatz) kommt von Domain X und der Upload hat das Ziel Y. Moderne Browser weigern sich, weil man damit anderen Domains Zeug unterschieben kann. Davon unberührt sind Uploads, die irgendwelche maliziösen Programme direkt ausführen, ohne den Browser eines Anwenders zu bemühen.
Please note that all provided implementations allow cross-site file uploads. If you don't need that functionality, you should remove the code parts that set the "Access-Control-Allow" headers.
Mit diesem Header erlaubt der Server des Scripts dem Browser die angegebenen Domains als Ziel für den Datentransfer zu verwenden. Ansonsten sperren sich die Browser - zumindest jene, die diesen Sicherheitsmechanismus eingebaut haben. Andere und alle Nicht-Browser-Clients sind davon unberührt.
dedlfix.
-
ist zumindest eine Dateiendungsprüfung vorzunehmen und nur ein paar harmlose Endungen sollten gestattet werden.
Die Namensendung sichert keine Eigenschaften des Dateiinhalts zu und da es auf jedem Server ein Leichtes ist, selbständig den Inhaltstyp zu ermitteln (Stichwort mimetype), in der Regel mit dem gleichen Aufwand wie deine Endungsprüfung, erscheint mir dein Hinweis eher aus der Kategorie Kinderkram zu stammen.
Mächtiges Unwohlsein breitet sich bei mir aus, wenn ich daran denke, dass ein großer Teil der in Benutzung befindlichen Browser sich bisweilen weder um Endung, noch um vom Server mitgeteilten Typ kümmert, sondern empfangene Daten nach Gutdünken selbst bestimmt und verarbeitet. Da ist dein toller Tipp dann für Server, die hochgeladene Daten sofort wieder zum Runterladen zur Verfügung stellen sollen, ein kapitaler Griff ins Klo.
-
Tach!
ist zumindest eine Dateiendungsprüfung vorzunehmen und nur ein paar harmlose Endungen sollten gestattet werden.
Die Namensendung sichert keine Eigenschaften des Dateiinhalts zu und da es auf jedem Server ein Leichtes ist, selbständig den Inhaltstyp zu ermitteln (Stichwort mimetype), in der Regel mit dem gleichen Aufwand wie deine Endungsprüfung, erscheint mir dein Hinweis eher aus der Kategorie Kinderkram zu stammen.
Die Namenseindung entscheidet in der Regel, was der Server damit macht. Endet eine Datei auf .php, wird sie meist auf dem Server ausgeführt. Endet sie auf .png, passiert auf dem Server meist nichts weiter als eine Auslieferung mit dem dazu konfigurierten Content-Type.
Mächtiges Unwohlsein breitet sich bei mir aus, wenn ich daran denke, dass ein großer Teil der in Benutzung befindlichen Browser sich bisweilen weder um Endung, noch um vom Server mitgeteilten Typ kümmert, sondern empfangene Daten nach Gutdünken selbst bestimmt und verarbeitet. Da ist dein toller Tipp dann für Server, die hochgeladene Daten sofort wieder zum Runterladen zur Verfügung stellen sollen, ein kapitaler Griff ins Klo.
Was die Browser damit machen, kann ich kaum beeinflussen. Mein Anliegen war hauptsächlich, die Sicherheit des Servers nicht zu gefährden, was der Fall wäre, wenn auf dem Server ausführbare Dateien innerhalb des DocumentRoot landen.
Mein erster Vorschlag war ja eine Überprüfung seitens des Serverbetreibers. Das ist nur leider nicht mit allen Anwendungsfällen kompatibel. Was wäre denn ein weniger kapitaler Griff ins Klo, wenn Dateien sofort zum Abruf bereitgestellt werden sollen? Eine umfassende Inhaltsprüfung findet auf dem Server nicht statt. Das was man da üblicherweise als mimetype-Erkennung auf dem Server hat, ist nichts weiter als das Überprüfen von ein paar wenigen "Magic Bytes", um daraus auf den Inhalt zu schließen. Ob der dann irgendwelche Programmierfehler ausnutzend Unheil anstellen kann, ist nicht Gegenstand der Prüfung. Insofern ist eine solche Prüfung nicht viel mehr wert als eine Prüfung der Dateiendung.
Vielen Dank für den ziemlich unfreundlichen Anschiss.
dedlfix.
-
erscheint mir dein Hinweis eher aus der Kategorie Kinderkram zu stammen.
Da ist dein toller Tipp dann für Server, die hochgeladene Daten sofort wieder zum Runterladen zur Verfügung stellen sollen, ein kapitaler Griff ins Klo.
Wie bist Du denn drauf? Dein Beitrag scheint eine ganz andere Intention zu haben als dem TO zu helfen. Soviel zum Stichpunkt "Kinderkram". Schäm' Dich!
Jonny
-
-
Tach!
Vorab möchte ich mich mit dem Thema Sicherheit/Datenschutz in diesem Kontext auseinandersetzen.
- Könnt Ihr mir Tipps geben, was ich beachten muss?
Das Upload-Verzeichnis sollte außerhalb des DocumentRoot liegen, damit nicht jemand Zeugs hochlädt und gleich vom Webserver ausführen lassen kann. Sollte das heutzutage immer noch nicht seitens des Providers gehen, so ist ein Wechsel dringend angeraten.
ich dachte, hochgeladene Dateien werden immer in das i.d. php.ini definierte upload_temp_dir hochgeladen und dann bspw. mit php per move_uploaded_file verschoben. Insofern würde ich denken, wenn das upload_temp_dir ausserhalb des DocRoot definiert ist (wovon ich ausgehe) liegt es in meiner Verantwortung, wohin ich die Files verschiebe.
Sollen die Dateien sofort zum Download zur Verfügung stehen und du keine händische Prüfung vornehmen möchtest, ist zumindest eine Dateiendungsprüfung vorzunehmen und nur ein paar harmlose Endungen sollten gestattet werden.
zunächst ist nicht geplant, die Files zum Download anzubieten. Das Plugin, dass ich einsetzen möchte, zeigt nach der Auswahl der Datei(en) von der lokalen Festplatte ein Thumbnail der Datei an sofern es sich um eine Grafik handelt, aber die Funktion ist m.E. Teil der HTML5 File Api. Und, ohne mich damit nun weiter auseinander gesetzt zu haben, würde ich denken, die Technik ist soweit sicher.
- Wie muss ich mir "cross domain file upload" vorstellen?
Das Script mit dem File-Upload-Formular (oder deinem Javascript-Aufsatz) kommt von Domain X und der Upload hat das Ziel Y. Moderne Browser weigern sich, weil man damit anderen Domains Zeug unterschieben kann. Davon unberührt sind Uploads, die irgendwelche maliziösen Programme direkt ausführen, ohne den Browser eines Anwenders zu bemühen.
Please note that all provided implementations allow cross-site file uploads. If you don't need that functionality, you should remove the code parts that set the "Access-Control-Allow" headers.
Mit diesem Header erlaubt der Server des Scripts dem Browser die angegebenen Domains als Ziel für den Datentransfer zu verwenden. Ansonsten sperren sich die Browser - zumindest jene, die diesen Sicherheitsmechanismus eingebaut haben. Andere und alle Nicht-Browser-Clients sind davon unberührt.
dedlfix.
-
Tach!
Das Upload-Verzeichnis sollte außerhalb des DocumentRoot liegen, damit nicht jemand Zeugs hochlädt und gleich vom Webserver ausführen lassen kann.
ich dachte, hochgeladene Dateien werden immer in das i.d. php.ini definierte upload_temp_dir hochgeladen und dann bspw. mit php per move_uploaded_file verschoben. Insofern würde ich denken, wenn das upload_temp_dir ausserhalb des DocRoot definiert ist (wovon ich ausgehe) liegt es in meiner Verantwortung, wohin ich die Files verschiebe.
Genau das Zielverzeichnis des Verschiebens meinte ich, da die temporäre Datei ja nur für die Dauer des entgegennehmenden Scripts im upload_temp_dir verweilt und an dessen Ende gelöscht wird. Deswegen musst du sie ja verschieben und deswegen spielt auch nur dieses Zielverzeichnis eine Rolle - zumindest in meiner Betrachtung. Dass das upload_temp_dir unvernünftigerweise im DocumentRoot liegt, ist hoffentlich nicht in freier Wildbahn anzutreffen.
Und, ohne mich damit nun weiter auseinander gesetzt zu haben, würde ich denken, die Technik ist soweit sicher.
Versuch mal ein paar Dateien mit kritischem Endungen (.php) und auch gefälschtem Inhalt (PHP als .png oder .jpg getarnt) hochzuladen und schau, dass das nciht ausgeführt wird (lass die Testscripte irgendwo eine Datei erzeugen, deren Hoffentlich-Nichtexistenz du prüfen kannst. (Und vorher testen, ob das Script bei ordentlichem Aufruf die Datei anlegen kann).
dedlfix.
-
Hallo heinetz,
ich stehe vor der Aufgabe, auf einer Website einen File-Upload einzubauen. Das würde ich mit einem jQuery-Plugin umsetzen. Vorab möchte ich mich mit dem Thema Sicherheit/Datenschutz in diesem Kontext auseinandersetzen.
@Jörg Reinholz hat einen sehr ausführlichen Wiki-Artikel dazu verfasst.
Bis demnächst
Matthias--
Signaturen sind bloed (Steel) und Markdown ist mächtig.-
Servus!
Das war Tom :-)
Matthias Scharwies
-
Lieber Matthias,
Das war Tom :-)
zu einem nicht unerheblichen Teil, ja. Weil wir aber schon über diesen Artikel reden, habe ich mir die Freiheit genommen, ihn um Plupload zu erweitern. Passt das so?
Liebe Grüße,
Felix Riesterer.
-
-
-
Hallo Forum,
Das Plugin, dass ich einsetzen will bedient sich der HTML5 Javascript File Api. Damit ist es möglich, dem User direkt nach der Auswahl seiner Datei(en) mit dem Dateibrowser Informationen zu diesen im Browser darzustellen. Bspw. Thumbnails von ausgewählten Bildern. Mit meinem Upload-Skript sollen aber nur PDFs hochgeladen werden können.
Folgendes habe ich bis hierher verstanden:
- Vom User hochgeladene Files landen grundsätzlich erstmal im upload_temp_dir.
- Sämtliche Informationen zu dem hochgeladenen File, die vom Browser mitgesendet werden sind unsicher.
Daraus folgt m.E.
-
Dass hochgeladene Files auf dem Server erst dann Schaden anrichten können, wenn Sie aus dem upload_temp_dir herausgeholt werden. Voraussetzung ist natürlich, dass die über die php.ini definierten Direktiven (upload_tmp_dir, upload_max_filesize etc.) den Server nicht schon gefährden.
-
Sämtliche Behandlung der hochzuladenden Files im Frontend ist im Grunde irrelevant für die Sicherheit des Servers, sondern dient nur dem GUI.
-
Sobald ich die hochgeladenen Dateien aus dem upload_tmp_dir verschiebe, muss ich sie mit PHP prüfen.
Weil die Dateien aber natürlich nicht im upload_tmp_dir verbleiben sollen, sondern ich damit etwas machen möchte, stellen sich die nächsten Fragen:
Geplant ist, die hochgeladenen Daten nicht dauerhaft zu speichern, sondern per Mail zu verschicken. Ganz naiv würde ich denken, dazu muss ich die Datei garnicht aus dem upload_tmp_dir herausholen, sondern:
- nehme ich die notwendigen Prüfungen an $_FILES['mein_upload']['tmp_name'] vor
- versende ich $_FILES['mein_upload']['tmp_name'] dann als Anhang in einer Mail. Etwa so:
$email = new PHPMailer(); $email->From = 'you@example.com'; $email->FromName = 'Your Name'; $email->Subject = 'Message Subject'; $email->Body = $bodytext; $email->AddAddress( 'destinationaddress@example.com' ); $email->AddAttachment($_FILES['mein_upload']['tmp_name'], 'NameOfFile.pdf' ); return $email->Send();Habe ich etwas vergessen oder gibt's nen Grund, die Hände über'm Kopf zusammenzuschlagen?
gruss, heinetz
-
Tach!
3. Sobald ich die hochgeladenen Dateien aus dem upload_tmp_dir verschiebe, muss ich sie mit PHP prüfen.
Jein. Du musst die Dateien aus dem upload_tmp_dir verschieben, weil sie sonst verlorengehen - vorausgesetzt, sie sollen das Ende des Scripts überleben. Die Frage ist nun, was damit passieren soll. Es reicht erstmal, für diesen Schritt relevante Prüfungen vorzunehmen. Prüfungen für weitere Schritte kann man jetzt schon vornehmen, kann man aber auch für später aufheben. Du kannst allerdings da schon prüfen, ob das eine Datei ist, die du überhaupt nicht haben möchtest.
Geplant ist, die hochgeladenen Daten nicht dauerhaft zu speichern, sondern per Mail zu verschicken. Ganz naiv würde ich denken, dazu muss ich die Datei garnicht aus dem upload_tmp_dir herausholen, sondern:
- nehme ich die notwendigen Prüfungen an $_FILES['mein_upload']['tmp_name'] vor
- versende ich $_FILES['mein_upload']['tmp_name'] dann als Anhang in einer Mail. Etwa so:
Passt. Wenn sie nur gelesen werden soll und dann nicht mehr gebraucht wird, muss man sie nicht noch durch die Weltgeschichte verschieben und einen Haufen Code einbauen, der das verwaltet.
Habe ich etwas vergessen oder gibt's nen Grund, die Hände über'm Kopf zusammenzuschlagen?
Ist mir jetzt nichts weiter aufgefallen. - Bei den nicht zitierten Teilen musst du dir ein Kopfnicken meinerseits dazu vorstellen.
dedlfix.
-
Ist mir jetzt nichts weiter aufgefallen. - Bei den nicht zitierten Teilen musst du dir ein Kopfnicken meinerseits dazu vorstellen.
Das sind gute Nachrichten! Danke ;)
Gut, dann will ich jetzt mal die Ecken des Projekts ausleuchten. Also, der User kann also seine Files hochladen. Dazu muss er sich nicht vorher authentifizieren, sondern nur seine Kontaktdaten mit übermitteln. In dem entgegennehmenden Skript könnte ich mit den Informationen aus $_FILES und $_POST eine Mail generieren.
- Überlegung Mein Upload-Plugin stellt, wie gesagt nach der Auswahl der Datei(en) mit dem Dateibrowser Thumnails der ausgewählten Dateien in Browser dar, sofort es sich um jpg/png/etc handelt. Das Funktioniert mit der HTML5 Javascript File Api, also clientseitig vor dem Upload. Da in meinem Fall PDFs hochgeladen werden sollen, wäre es ja komfortabel, von der ersten Seite des jeweiligen PDFs ein Thumbnail zu generieren. Was ist dazu notwendig?
Nach dem was ich dazu gefunden habe, benötigt man dazu auf dem Server 'Ghostscript' und 'Imagemagick' und kann dann mit PHP aus einem PDF[pages][0] ein jpg machen. Das Ganze geht natürlich erst nachdem sich das PDF auch a.d. Server befindet. Auch hier liesse sich vielleicht denken, das Thumbnail direkt aus dem upload_tmp_dir heraus zu generieren, aber möglicherweise muss ich nun doch anfangen, darüber nachzudenken Files a.d. Server zu speichern. Daraus resultieren zwei Anforderungen:
a) Die Files sollen nur dem User zur Verfügung stehen, dem sie zuzuordnen sind. b) Die Files müssen wieder gelöscht werden.
Mit war so, als hätte ich irgendwo was aufgeschnappt, dass das im Zusammenhang mit Session geht. Quasi ein Verzeichnis, dass innerhalb der Session zur Verfügung steht, damit klar einem User zuzuordnen wäre und auch nur so lange existiert. Gibt es sowas?
gruss, heinetz
-
Tach!
a) Die Files sollen nur dem User zur Verfügung stehen, dem sie zuzuordnen sind. b) Die Files müssen wieder gelöscht werden.
Mit war so, als hätte ich irgendwo was aufgeschnappt, dass das im Zusammenhang mit Session geht.
Eine Session speichert Daten zu einem Nutzer, den man über ein Token identifiziert, das meist in einem Cookie abgelegt wird. PHPs Session-Mechanismus ist hinreichend einfach zu verwenden und auch oft dokumentiert.
Quasi ein Verzeichnis, dass innerhalb der Session zur Verfügung steht, damit klar einem User zuzuordnen wäre und auch nur so lange existiert. Gibt es sowas?
Njein. Eine Session ist eine Datei, in der die Daten serialisiert abgelegt sind. Um eine Datei einer Session zuzuordnen, kannst du ihren Inhalt in die Session schreiben, oder nur ihren Dateinamen und sie anderswo ablegen. Im ersten Fall verfällt der Inhalt zusammen mit der Session, im zweiten nicht. Der PHP-interne Session-Garbage-Collector räumt zwar auf, hat aber keine Schnittstelle, über die man sich in den Löschprozess einklinken könnte, um so noch weitere Aufgaben zu erledigen. Das kannst zwar den eingebauten SessionHandler beerben und damit alles oder auch nur Teilaspekte überschreiben, kannst aber auch hier nicht nur den Löschvorgeng überschreiben, sondern musst den gesamten Garbage-Collection-Teil ersetzen.
Siehe PHP-Handbuch zu den Sessions, dort den Teil SessionHandler - The SessionHandler class.
dedlfix.
-
hello
Quasi ein Verzeichnis, dass innerhalb der Session zur Verfügung steht, damit klar einem User zuzuordnen wäre und auch nur so lange existiert. Gibt es sowas?
ich hab's gefunden! Das Plugin selbst bringt so eine Funktionalität mit : Das vom User hochgeladene File wird in einem Verzeichnis abgelegt, das heisst wie die Session-ID. Auf diese Weise hat der User innerhalb der Session die Möglichkeit, auf die von ihm hochgeladenen Files zuzugreifen, um sie bspsw. nach dem Upload wieder zu löschen
Njein. Eine Session ist eine Datei, in der die Daten serialisiert abgelegt sind. Um eine Datei einer Session zuzuordnen, kannst du ihren Inhalt in die Session schreiben, oder nur ihren Dateinamen und sie anderswo ablegen. Im ersten Fall verfällt der Inhalt zusammen mit der Session, im zweiten nicht.
Der problematische Teil meiner Aufgabe, ist ja dafür zu Sorge zu tragen, dass die hochgeladenen Files auch wieder vom Server verschwinden werden. Daher der Ansatz, sie direkt aus dem upload_tmp_dir per Mail zu verschicken.
Darum, dass die Dateien im session_save_path gelöscht werden kümmert sich der Server selbst. Da nun das vom Plugin angelegte Verzeichnis nur so lange existent sein muss/darf, wie die entsprechende Datei im session_save_path, müsste man nicht einfach regelmässig prüfen, welches Verzeichnis "noch gültig" ist, oder anders ausgedrückt, alle löscht, zu denen es keine entsprechende Datei mehr im session_save_path gibt? Vergesse ich dabei irgendetwas?
Die hochgeladenen Dateien sollen überigens nicht mehr per Mail verschickt sondern per FTP auf einen anderen Server geladen werden. Ich denke aber, das dürfte im Grunde keinen grundsätzlichen Unterschied machen.
gruss, heinetz
-
Tach!
Der problematische Teil meiner Aufgabe, ist ja dafür zu Sorge zu tragen, dass die hochgeladenen Files auch wieder vom Server verschwinden werden. Daher der Ansatz, sie direkt aus dem upload_tmp_dir per Mail zu verschicken.
Darum, dass die Dateien im session_save_path gelöscht werden kümmert sich der Server selbst.
Hmm, mir ist nicht bekannt, ob der eingebaute Session-Mechanismus sich auch um Verzeichnisse kümmert. Auf alle Fälle kümmert sich nicht um Dateien, die anders benannt sind als das Muster, das der Sessionmechanismus verwendet. Wenn dein Plugin allerdings einen eigenen Session-Handler verwenden sollte, ...
Da nun das vom Plugin angelegte Verzeichnis nur so lange existent sein muss/darf, wie die entsprechende Datei im session_save_path, müsste man nicht einfach regelmässig prüfen, welches Verzeichnis "noch gültig" ist, oder anders ausgedrückt, alle löscht, zu denen es keine entsprechende Datei mehr im session_save_path gibt? Vergesse ich dabei irgendetwas?
Klingt nach einem Plan. Aber beachte, dass dann der session_save_path auf ein eigenes Verzeichnis zeigen sollte und nicht auf sowas Globales wie beispielsweise /tmp. Das ist überigens eine generell gute Idee, nicht nur für diesen Anwendungsfall. Denn der Garbage Collector wirft alles weg, was in sein Schema passt, unabhängig davon, dass andere PHP-Scripts andere Einstellungen für ihre Sessions haben können.
Die hochgeladenen Dateien sollen überigens nicht mehr per Mail verschickt sondern per FTP auf einen anderen Server geladen werden. Ich denke aber, das dürfte im Grunde keinen grundsätzlichen Unterschied machen.
Zumindest nicht für deine Seite. Wie es auf dem FTP-Server aussieht, steht auf einem anderen Blatt. FTP ist übrigens schon lange nicht mehr wirklich Stand der Technik, obwohl es noch so oft eingesetzt wird. PHP kann auch SSH-basierende Dateiübertragungen.
dedlfix.
-
-
-
Lieber heinetz,
prinzipiell stimme ich Dir bei Deinen Überlegungen zu - aber beim Benutzen des JavaScript-Plugins verlierst Du eventuell prinzip-bedingt den Überblick.
- Werden alle Dateien immer komplett bei einem einzigen Request hochgeladen?
- Entspricht das Upload-Limit dem Mailanhangslimit?
Du darfst gerne mal meinen Zusatz zu Toms Artikel anschauen, um zu sehen, was ich mit "immer komplett hochgeladen" infrage stelle.
Liebe Grüße,
Felix Riesterer.
-
Hallo Forum,
ich umreisse meine Aufgabe nochmal neu.
Es soll eine Web-Anwendung entstehen, mit der es möglich ist, mehrere PDF-Files hochzuladen. Neben den Files sollen Informationen, die der User in Formularfelder eingibt, übertragen werden. Die hochgeladenen Files sollen nach dem Upload auf einen entfernten Server übertragen und die Infos aus den Formularfeldern per Mail an admin versandt werden.
- Es sollen nur PDFs hochgeladen werden.
- Die PDFs dürfen eine best. Dateigrösse nicht übersteigen.
- Auch für zusätzlich über Formularfelder eingegebenen Informationen müssen einem best. Format folgen.
Die Aufgabe im Frontend:
Das Frontend ist im Grunde nur eine HTML5-Seite mit einem Multipart-Form. Eine Validierung im Frontend wird mit jQuery bzw. Javascript umgesetzt. Das Formular wird per Ajax versandt.
Die Aufgabe im Backend:
Im Backend werden die übertragenen Daten als erstes nochmals mit PHP validiert. Ja nachdem, ob die Daten valide sind, wird entweder eine negative oder positive Rückmeldung als Response auf den Ajax-Request zurückgegeben und im Frontend ausgewertet. Sind die Daten valide werden sie ausserdem per FTP auf einen anderen Server übertragen und es wird eine Mail generiert. Sind sie es nicht verbleiben sie im upload_tmp_dir.
Lösung:
Das HTML5-Frontend soll mit Bootstrap umgesetzt werden. Für den Versand des Formulars per Ajax will ich das jQuery-Form-Plugin einsetzen und für die Validierung das jQuery-Plugin validate. Um die Daten im Backend zu validieren, orientiere ich mich an dem sehr ausführlichen Wiki-Artikel von @Jörg Reinholz.
Bei diesen Dingen bin ich mir unsicher:
-
IE<10 Wenn ich das richtig verstanden habe, gibt es damit 2 Einschränkungen für meine Anwendung. Hit Hilfe der Javascript File Api kann ich auf die Dateien, die der User per Filebrowser auswählt (lesend) zugreifen. Bilder könnten angezeigt werden, bevor sie hochgeladen werden, was für mich unerheblich ist, denn es sollen ja PDFs hochgeladen werden. Aber die Dateigrösse kann der per Filebrowser ausgewählten Files kann man anzeigen. Das Feature wird es für den IE<10 nicht geben. Zum Anderen kann der IE<10 von Haus aus keine Ajax-Requests vom Typ multipart/form-data. Die Übertragung funktioniert aber auf Umwegen und darum kümmert sich das jQuery-Form-Plugin ;) Gibt's noch mehr, was ich beim IE beachten muss?
-
Prozess-Balken Ein Feature, dass das jQuery-Form-Plugin bietet, ist ein Prozessbalken beim Upload (so_und_soviel_%_hochgeladen …). So einen Prozessbalken sieht man überall, wie ich ihn mit meinem jQuery-Form-Plugin erzeuge, ist schnell herausgefunden. Aber was dahinter steckt ist mir nicht ganz klar.
var ajax = new XMLHttpRequest(); ajax.upload.addEventListener("progress", function(event){ console.log(event.loaded); }, false);- Das JS-Objekt XMLHttpRequest hat eine Eigenschaft upload.
- Dieser wird ein Eventlistener "progress" hinzugefügt.
- Der Event hat wiederum Eigenschaften wie bspw. loaded
Richtig? Das Ganze hat nichts mit PHP zu tun, wenn ich das richtig verstehe. Meine Frage zielt darauf ab:
In meinem Fall ist der "Prozess" ja nicht damit abgeschlossen, wenn die Files vollständig auf den Server geladen wurden. Was darauf folgt, ist zuerst die Validierung durch PHP und danach der Upload aus dem upload_tmp_dir auf einen FTP-Server. Von daher stellt sich die Frage, ob ich auch den Teil mit einem Prozessbalken darstellen kann.
Ist das denkbar?
gruss, heinetz
-
Tach!
Die nicht zitierten Fragen kann ich nicht beantworten.
- Prozess-Balken Ein Feature, dass das jQuery-Form-Plugin bietet, ist ein Prozessbalken beim Upload (so_und_soviel_%_hochgeladen …). So einen Prozessbalken sieht man überall, wie ich ihn mit meinem jQuery-Form-Plugin erzeuge, ist schnell herausgefunden. Aber was dahinter steckt ist mir nicht ganz klar.
var ajax = new XMLHttpRequest(); ajax.upload.addEventListener("progress", function(event){ console.log(event.loaded); }, false);- Das JS-Objekt XMLHttpRequest hat eine Eigenschaft upload.
- Dieser wird ein Eventlistener "progress" hinzugefügt.
- Der Event hat wiederum Eigenschaften wie bspw. loaded
Richtig? Das Ganze hat nichts mit PHP zu tun, wenn ich das richtig verstehe.
Richtig. Das Event progress wird von XMLHttpRequest (Level 2) zur Verfügung gestellt.
Meine Frage zielt darauf ab:
In meinem Fall ist der "Prozess" ja nicht damit abgeschlossen, wenn die Files vollständig auf den Server geladen wurden. Was darauf folgt, ist zuerst die Validierung durch PHP und danach der Upload aus dem upload_tmp_dir auf einen FTP-Server. Von daher stellt sich die Frage, ob ich auch den Teil mit einem Prozessbalken darstellen kann.
Das passiert ja direkt im Anschluss, wenn der Ajax-Request die Datei fertig hochgeladen hat. Der wartet dann auf die Antwort vom Server. Du müsstest aber statt einer Response mehrere Fortschrittsinformationen senden. Und nun musst du mal schauen, was das XMLHttpRequest für Möglichkeiten hat. Um es vorwegzunehmen: nicht viele. Es gibt da das onreadystatechanged-Event und dazu die Werte, die readystate annehmen kann. State loading (=3) sieht noch am vielversprechendsten aus. Die Frage ist nur, wie oft das gefeuert wird, bevor done (=4) kommt. Da musst du mal schauen, wie sich das verhält, wenn du am Server ein paar Mal flush() und sleep() und eine Ausgabe machst.
dedlfix.
-
hello,
In meinem Fall ist der "Prozess" ja nicht damit abgeschlossen, wenn die Files vollständig auf den Server geladen wurden. Was darauf folgt, ist zuerst die Validierung durch PHP und danach der Upload aus dem upload_tmp_dir auf einen FTP-Server. Von daher stellt sich die Frage, ob ich auch den Teil mit einem Prozessbalken darstellen kann.
Das passiert ja direkt im Anschluss, wenn der Ajax-Request die Datei fertig hochgeladen hat. Der wartet dann auf die Antwort vom Server. Du müsstest aber statt einer Response mehrere Fortschrittsinformationen senden. Und nun musst du mal schauen, was das XMLHttpRequest für Möglichkeiten hat. Um es vorwegzunehmen: nicht viele. Es gibt da das onreadystatechanged-Event und dazu die Werte, die readystate annehmen kann. State loading (=3) sieht noch am vielversprechendsten aus. Die Frage ist nur, wie oft das gefeuert wird, bevor done (=4) kommt. Da musst du mal schauen, wie sich das verhält, wenn du am Server ein paar Mal flush() und sleep() und eine Ausgabe machst.
Ja, ich werde mal damit herumprobieren. Einen anderen Ansatz, den ich mehrfach gefunden habe ist folgender:
Ein XMLHttpRequest ruft ein PHP-Skript auf, dass für die Verarbeitung der Daten zuständig ist. Dieses PHP-Skript schreibt während der Verarbeitung den Status der Verarbeitung irgendwo (z.b. Session) hin. Ein anderer XMLHttpRequest ruft ein anderes PHP-Skript auf, dass den Status der Verarbeitung ausliesst und zurückgibt. Dieser XMLHttpRequest wird per Intervall wiederholt aufgerufen.
Die Schwierigkeit sehe ich nur darin, dass die Verarbeitung nach dem Upload zum grössten Teil (= wird die meiste Zeit in Anspruch nehmen) darin bestehen dürfte, (das) hochgeladene File(s) mit PHP per FTP auf einen anderen Server zu übertragen. Die PHP-Funktion ftp_put() wird also aufgerufen, um eine Datei zu übertragen und wenn sie damit fertig ist, gibt sie TRUE zurück. Was sie aber tun müsste, damit ich daraus irgendwie meinen Prozessbalken konstruieren kann, wäre zwischendurch mal Bescheid zu geben, wie weit sie ist und was sie denkt, wie lange es noch dauern wird.
Man könnte (jetzt gehen deie Pferde mit mir durch;) vielleicht eine weitere Funktion dazu nutzen, regelmässig zu überprüfen, welche Dateigrösse der bereits übertragene Teil der Datei hat um diesen mit der Grösse des gesamten Files zu vergleichen. Ich habe aber das Gefühl, den Gedanken sollte ich verwerfen ;)
gruss, heinetz
-
Tach!
Die PHP-Funktion ftp_put() wird also aufgerufen, um eine Datei zu übertragen und wenn sie damit fertig ist, gibt sie TRUE zurück. Was sie aber tun müsste, damit ich daraus irgendwie meinen Prozessbalken konstruieren kann, wäre zwischendurch mal Bescheid zu geben, wie weit sie ist und was sie denkt, wie lange es noch dauern wird.
Schau mal ins FTP-Kapitel im PHP-Handbuch. Da gibt es auch non-blocking Funktionen ...
dedlfix.
-
hi,
zu meiner Aufgabenstellung erreicht mich gerade eine nicht unerhebliche Information : der Upload via Formular soll dem User ermöglichen, bis zu 10 Files bis zu je 100 MB hochzuladen. Wenn ich richtig gerechnet habe macht das, dass hier von 1 GB (!) die Rede ist.
Gut, das sind ne Menge Daten. Aber aus meiner Sicht dürfte das nur bedeuten, dass der User dann entsprechend lange warten muss. Technisch bedeutet das nur, dass die entsprechenden Restriktionen in der php.ini für die Anforderung angepasst werden muss.
Oder ?
Und die Frage danach, wie ich das Verschieben der hochgeladenen Dateien per ftp_put() nach dem Upload als Prozessbalken darstellen kann, stellt sich nicht mehr. Vielmehr ist zu überlegen, ob ich dafür sorgen kann, dass dieses Verschieben nach dem Upload durchgeführt wird, ohne dass der User darauf warten muss.
geht das mit:
ignore_user_abort(true)
?
beste gruesse, heinetz
-
Hi,
Gut, das sind ne Menge Daten. Aber aus meiner Sicht dürfte das nur bedeuten, dass der User dann entsprechend lange warten muss. Technisch bedeutet das nur, dass die entsprechenden Restriktionen in der php.ini für die Anforderung angepasst werden muss.
Bei den Größenordnungen könnte ich mir vorstellen, daß auch an der Konfiguration des Webservers noch entsprechende Änderungen vorgenommen werden müssen.
cu,
Andreas a/k/a MudGuard -
Tach!
Gut, das sind ne Menge Daten. [...] Technisch bedeutet das nur, dass die entsprechenden Restriktionen in der php.ini für die Anforderung angepasst werden muss.
Oder ?
Wie schon gemutmaßt, auch der Webserver hat Begrenzungen. Je nach Konfiguration auch mehrere. Beispielsweise hat der Apache auf alle Fälle eine und wenn PHP als FCGI eingebunden ist, dann hat auch das FCGI-Progamm eine.
Die Gesamtgröße spielt keine Rolle mehr, wenn jede Datei mit ihrem eigenem Request verarbeitet wird.
Vielmehr ist zu überlegen, ob ich dafür sorgen kann, dass dieses Verschieben nach dem Upload durchgeführt wird, ohne dass der User darauf warten muss.
Wenn es nur um den move_uploaded_file() geht, der sollte nicht ins Gewicht fallen, wenn die Verschiebung innerhalb der Partition bleibt. Ansonsten wäre ein Background-Prozess angebracht, beispielsweise ein Cronjob, der die Aufgaben erledigt, die in eine Queue eingereiht wurden.
dedlfix.
-
Tach!
Gut, das sind ne Menge Daten. [...] Technisch bedeutet das nur, dass die entsprechenden Restriktionen in der php.ini für die Anforderung angepasst werden muss.
Oder ?
Wie schon gemutmaßt, auch der Webserver hat Begrenzungen. Je nach Konfiguration auch mehrere. Beispielsweise hat der Apache auf alle Fälle eine und wenn PHP als FCGI eingebunden ist, dann hat auch das FCGI-Progamm eine.
Das hatte ich nicht erwartet! Ich habe aber schon einiges gefunden:
FcgidMaxRequestLen(PHP-FCGI), FcgidBusyTimeout(PHP-FCGI), LimitRequestBody(Apache)
… was nicht mal alles sein muss. Nun soll das Ganze nicht auf einem shared hosting Webserver umgesetzt werden und der Kunde hat eine eigene IT-Abteilung. Die notwendigen Konfigurationen könnten also theoretisch vorgenommen werden … theoretisch.
Die Gesamtgröße spielt keine Rolle mehr, wenn jede Datei mit ihrem eigenem Request verarbeitet wird.
Diesen Satz weiss ich nicht so richtig zu deuten. Klar, für 10 HTTP-Uploads á 100MB werden die Konfigurationen für 100MB vorgenommen werden müssen und nicht für 10*100MB. Meinst Du damit, für 100MB werden keine aussergewöhnlichen Anpassungen der Konfiguration vorgenommen werden müssen?
Vielmehr ist zu überlegen, ob ich dafür sorgen kann, dass dieses Verschieben nach dem Upload durchgeführt wird, ohne dass der User darauf warten muss.
Wenn es nur um den move_uploaded_file() geht, der sollte nicht ins Gewicht fallen, wenn die Verschiebung innerhalb der Partition bleibt. Ansonsten wäre ein Background-Prozess angebracht, beispielsweise ein Cronjob, der die Aufgaben erledigt, die in eine Queue eingereiht wurden.
Ich hatte ja ursprünglich geplant, die Files nach dem Upload und einer Validierung direkt im upload_tmp_dir per ftp_put() auf einen anderen Rechner zu verschieben um zu vermeiden, dass ich sie Files noch irgendwo zwischenlagern muss. Wenn Du sagst, ein Background-Prozess wäre angebracht, nehme ich das so an. Nur zum Verständnis: Ein Cronjob würde es erforderlich machen, die hochgeladenen Files aus dem upload_tmp_dir woanders hinzukopieren, oder? Denn nachdem das Script, dass den Multipart-Request en Empfang nimmt, sind abgearbeitet ist, werden sie irgendwann aus dem uolaod_tmp_dir gelöscht.
danke und gruss, heinetz
-
Tach!
Wie schon gemutmaßt, auch der Webserver hat Begrenzungen. Je nach Konfiguration auch mehrere. Beispielsweise hat der Apache auf alle Fälle eine und wenn PHP als FCGI eingebunden ist, dann hat auch das FCGI-Progamm eine.
Das hatte ich nicht erwartet! Ich habe aber schon einiges gefunden:
FcgidMaxRequestLen(PHP-FCGI), FcgidBusyTimeout(PHP-FCGI), LimitRequestBody(Apache)
Genau sowas. Je nach FCGI-Programm heißen die Konfigurationswerte auch anders.
Die Gesamtgröße spielt keine Rolle mehr, wenn jede Datei mit ihrem eigenem Request verarbeitet wird.
Diesen Satz weiss ich nicht so richtig zu deuten. Klar, für 10 HTTP-Uploads á 100MB werden die Konfigurationen für 100MB vorgenommen werden müssen und nicht für 10*100MB.
Wenn dir das schon klar ist, dann ist gut. Du hattest nur drei Postings vorher die Rechnung aufgemacht 10 × 100MB = 1GB. Darauf bezog ich mich.
Meinst Du damit, für 100MB werden keine aussergewöhnlichen Anpassungen der Konfiguration vorgenommen werden müssen?
Doch, doch, 100MB ist jenseits der Default-Werte. Die liegen bei wenigen MB.
Ich hatte ja ursprünglich geplant, die Files nach dem Upload und einer Validierung direkt im upload_tmp_dir per ftp_put() auf einen anderen Rechner zu verschieben um zu vermeiden, dass ich sie Files noch irgendwo zwischenlagern muss. Wenn Du sagst, ein Background-Prozess wäre angebracht, nehme ich das so an.
Das musst du selbst entscheiden. Wenn der FTP-Transfer auch bei großen Dateien unmerklich flott läuft, dann brauchst du keine Zwischenlagerung.
Nur zum Verständnis: Ein Cronjob würde es erforderlich machen, die hochgeladenen Files aus dem upload_tmp_dir woanders hinzukopieren, oder? Denn nachdem das Script, dass den Multipart-Request en Empfang nimmt, sind abgearbeitet ist, werden sie irgendwann aus dem uolaod_tmp_dir gelöscht.
Ja, für einen Cronjob braucht es einen weiteren Platz.
Aber schriebst du grad "Multipart-Request"? Dann kämest du ja doch wieder zur Rechnung 10 × 100MB = 1GB und damit auf Konfigurationswerte von 1GB statt 100MB. Bei solchen Größen würde ich nichr einen einzelnen Request mit vielen Teilen drin, sondern je Datei einen Request nehmen.
dedlfix.
-
Tach!
Wie schon gemutmaßt, auch der Webserver hat Begrenzungen. Je nach Konfiguration auch mehrere. Beispielsweise hat der Apache auf alle Fälle eine und wenn PHP als FCGI eingebunden ist, dann hat auch das FCGI-Progamm eine.
Das hatte ich nicht erwartet! Ich habe aber schon einiges gefunden:
FcgidMaxRequestLen(PHP-FCGI), FcgidBusyTimeout(PHP-FCGI), LimitRequestBody(Apache)
Genau sowas. Je nach FCGI-Programm heißen die Konfigurationswerte auch anders.
Die Gesamtgröße spielt keine Rolle mehr, wenn jede Datei mit ihrem eigenem Request verarbeitet wird.
Diesen Satz weiss ich nicht so richtig zu deuten. Klar, für 10 HTTP-Uploads á 100MB werden die Konfigurationen für 100MB vorgenommen werden müssen und nicht für 10*100MB.
Wenn dir das schon klar ist, dann ist gut. Du hattest nur drei Postings vorher die Rechnung aufgemacht 10 × 100MB = 1GB. Darauf bezog ich mich.
Richtig, hatte ich auch. Weil ich bis vorhatte, ein Formular mit 10 input[type=file] zu bauen. Das wären dann 10 * 100MB = 1GB. Wenn es irgendeinen Vorteil hat (bspw. dass ich dann nur die Konfigurationsparameter in der php.ini ändern muss), das ganze auf 10 Formulare, also 10 Requests aufzuteilen, würde ich das tun.
Meinst Du damit, für 100MB werden keine aussergewöhnlichen Anpassungen der Konfiguration vorgenommen werden müssen?
Doch, doch, 100MB ist jenseits der Default-Werte. Die liegen bei wenigen MB.
Ich hatte ja ursprünglich geplant, die Files nach dem Upload und einer Validierung direkt im upload_tmp_dir per ftp_put() auf einen anderen Rechner zu verschieben um zu vermeiden, dass ich sie Files noch irgendwo zwischenlagern muss. Wenn Du sagst, ein Background-Prozess wäre angebracht, nehme ich das so an.
Das musst du selbst entscheiden. Wenn der FTP-Transfer auch bei großen Dateien unmerklich flott läuft, dann brauchst du keine Zwischenlagerung.
Nur zum Verständnis: Ein Cronjob würde es erforderlich machen, die hochgeladenen Files aus dem upload_tmp_dir woanders hinzukopieren, oder? Denn nachdem das Script, dass den Multipart-Request en Empfang nimmt, sind abgearbeitet ist, werden sie irgendwann aus dem uolaod_tmp_dir gelöscht.
Ja, für einen Cronjob braucht es einen weiteren Platz.
Aber schriebst du grad "Multipart-Request"? Dann kämest du ja doch wieder zur Rechnung 10 × 100MB = 1GB und damit auf Konfigurationswerte von 1GB statt 100MB. Bei solchen Größen würde ich nichr einen einzelnen Request mit vielen Teilen drin, sondern je Datei einen Request nehmen.
Dann benutze ich die Begrifflichkeit "Multipart-Request" vielleicht falsch. Ich dachte, immer wenn per http etwas hochgeladen wird, spricht man von einem "Multipart-Request".
Ich hatte ursprünglich mal vor, ein Formular zu bauen, mit dem der User PDFs auf den Server laden kann. Diese PDFs sollten dann nach einer serverseitigen Validierung direkt aus dem upload_tmp_dir per Mail versendet werden. Über die Dateigrössen hatte ich mir nie Gedanken gemacht, bis dann klar wurde, dass sie sich nicht so einfach per Mail verschicken lassen, weil sie so gross sind. Gut, dachte ich mir, dann werden sie halt nicht per Mail verschickt, sondern mit php per ftp auf eine andere Maschine geladen. Dass sich die Aufgabenstellung aufgrund der Dateigrösse verändert, hatte ich nicht gedacht. In Deinem letzten Posting habe ich zwei, sagen wir mal, Impulse gelesen:
- Die Uploads in einzelne Requests aufteilen
- Die Weiterverarbeitung der Files nach dem Upload einen Hintergrundprozess machen lassen
Damit wird die Aufgabe komplexer aber beide klingen vernünftig. Nur warum?
-
Die Zeit, die der User warten muss, bis all seine Daten übertragen wurden unterscheidet sich ja nicht wesentlich dadurch, wenn für jedes input[type=file] ein eigener Request gestartet wird statt in eine Request alle Files auf einmal zu übertragen.
-
Wenn die Files nach dem Upload und einer Validierung mit php per ftp verschoben werden, ist es zunächst mal so, dass der User abwarten muss, bis php damit fertig ist. Deshalb hatte ich danach gesucht, ob sich das umgehen lässt und ignore_user_abort(true) gefunden. Keine Ahnung, ob es damit geht, ob das irgendwelche Problem nach sich zieht.
Obwohl ich nicht genau sagen kann warum, zweifle ich langsam an der Aufgabe an sich und ich weiss nicht mal warum ;)
gruss, heinetz
-
Tach!
Die Gesamtgröße spielt keine Rolle mehr, wenn jede Datei mit ihrem eigenem Request verarbeitet wird.
Diesen Satz weiss ich nicht so richtig zu deuten. Klar, für 10 HTTP-Uploads á 100MB werden die Konfigurationen für 100MB vorgenommen werden müssen und nicht für 10*100MB.
Wenn dir das schon klar ist, dann ist gut. Du hattest nur drei Postings vorher die Rechnung aufgemacht 10 × 100MB = 1GB. Darauf bezog ich mich.
Richtig, hatte ich auch. Weil ich bis vorhatte, ein Formular mit 10 input[type=file] zu bauen.
Also doch. Bei den geplanten Dateigrößen würde ich keinesfalls einen Mehrfach-Upload implementieren wollen. Schon eine Datei dieser Größenordnung sprengt ja die üblichen Limits und man muss die Konfigurationswerte aufbohren. Sich mehr Probleme als nötig aufzuhalsen, ist nicht empfehlenswert.
Auf Client-Seite muss man ja auf keinen Komfort verzichten. Da gibt es genügend Komponenten, zum Beispiel das von Felix Riesterer gern empfohlene Plupload. Das schickt die Dateien nacheinander über die Leitung, jede in einem eigenen Request.
Damit wäre der Client-Teil erledigt und der erste Teil der Serverseite, wenn man das in der Dokumentation gezeigte Minimalscript für PHP nimmt. Damit kannst du erstmal das Verhalten bei verschiedenen Dateigrößen testen.
1. Die Uploads in einzelne Requests aufteilen
Mit der erwähnten Komponente sollte das ganz einfach werden.
2. Die Weiterverarbeitung der Files nach dem Upload einen Hintergrundprozess machen lassen
Damit wird die Aufgabe komplexer aber beide klingen vernünftig. Nur warum?
Das Wegschieben per FTP musst du ja sowieso implementieren. Dem Teil sollte es egal sein, wo die Datei herkommt. Das kann man als Parameter übergeben. Für den Anfang ist es eben der temporäre Upload-Name, später denn - vielleicht - die Datei aus der Zwischenlagerung.
1. Die Zeit, die der User warten muss, bis all seine Daten übertragen wurden unterscheidet sich ja nicht wesentlich dadurch, wenn für jedes input[type=file] ein eigener Request gestartet wird statt in eine Request alle Files auf einmal zu übertragen.
Die clientseitige Komponente zeigt auf jeden Fall einen Fortschritt an. Ich weiß gar nicht, wie das bei einem nackigem input type=file in den Bowsern aussieht.
Und klar, die Laufzeit ist stark abhängig vom Uplink des Anwenders.
2. Wenn die Files nach dem Upload und einer Validierung mit php per ftp verschoben werden, ist es zunächst mal so, dass der User abwarten muss, bis php damit fertig ist. Deshalb hatte ich danach gesucht, ob sich das umgehen lässt und ignore_user_abort(true) gefunden. Keine Ahnung, ob es damit geht, ob das irgendwelche Problem nach sich zieht.
Da kann ich dir nicht mit Erfahrung dienen.
Obwohl ich nicht genau sagen kann warum, zweifle ich langsam an der Aufgabe an sich und ich weiss nicht mal warum ;)
Einfach mal klein starten. Erstmal kleine Dateien hochladen, ohne großartige serverseitige Verarbeitung. Dann die großen Boliden. Es ist dabei durchaus auch sinnvoll, das mit den normalen Konfigurationswerten zu probieren, damit man weiß, wie das aussieht, wenn man ans Limit stößt. Dann weiter mit dem Konfigurieren des Webservers für die großen Dinger. Nun das FTP-Verschieben direkt im Script testen und wenn das akzeptabel schnell ist, dann war's das schon. Bei Bedarf baust du noch die Cronjob-Variante dazu, aber zumindest hast du jetzt schon ein lauffähiges System.
dedlfix.
-
-
-
-
-
-
-
Lieber heinetz,
orientiere ich mich an dem sehr ausführlichen Wiki-Artikel von @Jörg Reinholz.
da steht im changelog aber kein Jörg, sondern ein Tom als wesentlicher Autor!
Ansonsten klinke ich mich aus der Diskussion aus. Meinen Beitrag habe ich in Form der Ergänzung zu obigem Artikel bereits geleistet.
Liebe Grüße,
Felix Riesterer.
-
Hallo Felix Riesterer,
orientiere ich mich an dem sehr ausführlichen Wiki-Artikel von @Jörg Reinholz.
da steht im changelog aber kein Jörg, sondern ein Tom als wesentlicher Autor!
Das war meine Schuld
Bis demnächst
Matthias--
Signaturen sind bloed (Steel) und Markdown ist mächtig.
-