Mit TL 2.8: Fehler beim Datei-Upload

[Babelfisch]

Hmm, dann bin ich mit meinem Latein auch am Ende.

[leo]

Ich habe den Aufruf jetzt noch mal verändert, um ohne das Setzen des Session-Namens auszukommen.

http://https://contao.org/repositori.../typolight/174

Bitte noch mal testen (vorher unbedingt den Browser-Cache leeren) und Feedback geben. Wenn das nicht hilft, weiß ich auch nicht mehr weiter …

[Sebastian]

HI

ich habe die neuste Revision getestet (und alle verfügbaren Caches geleert). Leider hilft es nicht

„Der Server hat den HTTP-Status #400 zurück gegeben“ (Übrigens heißt es „zurückgegeben“).

Offenbar ist es einfach merkwürdig. Es wäre schon, wenn du, oder irgendjemand, einfach einen Geistesblitz hat, aber die alte Möglichkeit tut zur Not auch noch.

Sebastian

[leo]

Der Status 400 deutet darauf hin, dass eine der Prüfungen am Anfang der upload.php fehlschlägt. Bist Du sicher, dass Du die neueste Version aus dem trunk verwendest und auch alle relavanten Dateien aktualisiert hast?

[Sebastian]

HI

eigentlich ja. Aus dem Subversion habe ich die neuste Revision heruntergeladen und per FTP (leider kein SSH) auf den Server gepackt. Aber ich kann es gerne nochmals machen, vielleicht ist ja auch etwas schiefgelaufen…

Oder möchstest du einen Zugang?

Sebastian

[leo]

Kann denn wenigstens jemand, bei dem es mit dem Workaround funktioniert hat, bestätigen, dass die neueste Lösung ohne session_id($_GET[session_name()]) ebenfalls funktioniert?

[Babelfisch]

Hab gerade den aktuellen Trunk installiert und er läuft problemlos bei mir. Scheint bei den anderen doch noch irgendein andere Problem zu sein.

[leo]

Vielen Dank für die Rückmeldung. Auf meinen Systemen funktioniert es auch ganz ohne die Zeile $_SESSION[session_name()]. Ist das bei Dir auch der Fall? Ob es doch etwas mit der Flash-Version zu tun hat?

[Babelfisch]

Ich schaue es mir morgen noch mal genauer an. Ich muss erst mal sehen, was du geändert hast und wie du es jetzt gelöst hast. So ganz schaue ich da momentan nicht durch. Du setzt doch jetzt die Session-ID aus dem POST-Daten direkt in den Cookie? Allerdings sehe ich in dem Formular nirgendwo ein HIDDEN-Feld, wo die Session-ID übergeben wird.

Heute bin ich aber zu geschafft dafür. Melde mich morgen noch mal.

[Sebastian]

HI

ich werde morgen mal auf dem gleichen Server eine komplett frische Installation einrichten, vielleicht sind ja doch nicht alle Dateien korrekt übertragen worden.

Sebastian

[leo]

Allerdings sehe ich in dem Formular nirgendwo ein HIDDEN-Feld, wo die Session-ID übergeben wird.

Das macht FancyUpload automatisch. Die wichtige Frage ist, ob der Code in der upload.php so funktioniert oder nicht. Muss man den Session-Namen explizit setzen oder reicht es, die Daten aus $_POST nach $_COOKIE zu verschieben?

[Babelfisch]

Muss man den Session-Namen explizit setzen oder reicht es, die Daten aus $_POST nach $_COOKIE zu verschieben?

Beides funktioniert. Ich hatte nur im Hinterkopf irgendwo mal gelesen zu haben, dass es ein Sicherheitsproblem sein kann, den Cookie direkt zu setzten. Deshalb hatte ich in meiner Version die Session-ID mit der Funktion session_id() gesetzt, was vielleicht der etwas sauberere Weg ist. Am Ende kommt aber das gleiche raus und ob es wirklich ein Sicherheitsproblem geben kann, weiß ich auch nicht.

[Babelfisch]

Hm, an der encrypt sollte es nicht liegen … die Session wird ja im Core gewandelt, also dürfte es egal sein, ob encrypt aktiviert ist oder nicht.

Ich hab mir noch mal die Doku von Suhosin angeschaut. Mit der Option cryptua ist die Session-Verschlüsselung durchaus ein sehr wahrscheinliches Problem. Mit dieser Option nimmt Suhosin auch den User-Agent zum Verschlüsseln, der sich ja beim FancyUpload unterscheidet und nicht mehr der Browser ist, sondern „Adobe Flash Player 10“. Damit kann die Session dann auch mit der richtigen Session-ID nicht gestartet/entschlüsselt werden.

An alle Suhosin-Nutzer noch mal die Bitte, Leos Änderungen mal ohne Suhosin zu testen und Suhosin dafür in den Simpulationsmodus zu schalten.

@Sebastian: Kannst du mal testen, wo bei dir der 400er Statuscode zurückgegeben wird – in der upload.php oder in der initialize.php?

[leo]

Ich hatte nur im Hinterkopf irgendwo mal gelesen zu haben, dass es ein Sicherheitsproblem sein kann, den Cookie direkt zu setzten.

Ich wüsste jetzt allerdings nicht, wieso das setzen des Cookies mehr oder weniger problematisch sein sollte als der Umweg über session_id(). Beides läuft auf dasselbe Ergebnis heraus.

@Sebastian: Kannst du mal testen, wo bei dir der 400er Statuscode zurückgegeben wird – in der upload.php oder in der initialize.php?

Ich glaube nicht, dass es die initialize.php ist, denn das Deaktivieren der Referer-Prüfung war ja eine der ersten empfohlenen Maßnahmen, um dem Problem auf die Spur zu kommen. Das hatten wir also schon ausgeschlossen.

[Babelfisch]

Ich wüsste jetzt allerdings nicht, wieso das setzen des Cookies mehr oder weniger problematisch sein sollte als der Umweg über session_id(). Beides läuft auf dasselbe Ergebnis heraus.

Kann ich dir auch nicht sagen. Ich hab das mal irgendwo gelesen, allerdings wurde da auch kein konkretes Problem genannt. Meine Überlegung war halt eher – wenn es schon eine dafür vorgesehene Funktion gibt, warum nicht nehmen? Aber wie schon gesagt, das Ergebnis ist das gleiche.

[leo]

Und funktioniert es bei Dir auch ganz ohne die Zeile $_SESSION[session_name()]?

[Babelfisch]

Und funktioniert es bei Dir auch ganz ohne die Zeile $_SESSION[session_name()]?

Du meinst $_COOKIE[session_name()] ? Nein, ohne diese Zeile oder eben session_id(…) geht es bei mir nicht.

[leo]

Ok, das wollte ich wissen. Dann lasse ich diese Lösung jetzt so stehen, damit die 2.8 irgendwann mal erscheinen kann

[Sebastian]

HI

so, jetzt habe ich auf dem lokalen Apache (auf dem der Fehler auch aufgetreten ist) noch eine frische Installation gemacht, und es tut

Vielen Dank für die vielen Patch-Versuche, irgendeiner war wohl erfolgreich!
Ich mache jetzt mal die Installation auf dem Fedora-Server platt und installiere dort neu. Mal sehen…

Einen schönen Sonntag noch,

Sebastian

[Sebastian]

HI

Update: Eine komplette Neuinstallation auf dem Fedora-Server hat nichts gebracht. Leider erscheint immer noch die Fehlermeldung.

Sebastian

[leo]

Nachdem wir die Implementierung inzwischen als Ursache ausschließen können, solltest Du FancyUpload mal direkt testen (ohne TYPOlight). Klappt das auch nicht, solltest Du Dich an den Entwickler wenden.

[Sebastian]

HI

alles klar, danke. Ich finde es schonmal gut, dass es auf meinem lokalen Server tut, mal sehen, ob ich FancyUpload einfach so zum Laufen bringe.

Sebastian

[alphabeet]

Ein grosses Dankeschön auch von mir für die vielen Neuerungen! TYPOlight ist nach wie vor der Hammer!

Super ist der Uploader, mit dem man mehrere Dateien gleichzeitig auswählen kann. Leider habe ich da ein Problem. Ich kann keine Dateien mehr raufladen. Bei mir kommt der Fehler:

Upload fehlgeschlagen: Der Server hat den HTTP-Status #406 zurückgegeben

Hat das sonst noch jemand? Wie lässt sich das beheben?
Danke euch.

[ATLAS]

@ alphabeet
Auch bei mir geht der Upload nicht mehr.

[aportmann]

ups, nun auch bei mir die erste fehlermeldung: upload ist nicht möglich

Upload fehlgeschlagen: Ein Lade- bzw. Sendevorgang wurde wegen eines Fehlers abgebrochen (Error #2038)

edit: ok, unter firefox gehts. safari (und somit auch chrome?) scheinen probleme zu haben. ist das nur bei mir so mit dem fancyupload?

[Nina]

Ich hatte das Problem gestern auch mit zwei Dateien, konnte aber den Grund nicht nachvollziehen. Mal schauen ob das reproduzierbar nochmal auftaucht, dann würde ich dazu ein Ticket machen.

[aportmann]

bei mir ist das relativ einfach zu reproduzieren. unter safari kann ich keine dateien uploaden

[jan.theofel]

Hi,

der fancyUpload läuft über ein Flash, dass die Dateien zum Server sendet. Da auch bei den beiden RCs Probleme gegeben hat, kann man das in der 2.8 final ausschalten.

Bei uns haben wir folgende Situation: Gleicher Server, gleiche Installation, gleicher Uploadpfad, gleiche Datei: Zwei verschiedene Firefox unter Linux laufen, Firefox unter Windows nicht, IEX nicht. (Genaue Versionen habe ich gerade nicht zur Hand.) Auch ein Update auf die neueste Flash-Version hat da leider nicht weiter geholfen.

Wir haben die HTTP-Uploads mal mitgetract und verglichen. Allerdings sind die zu unterschiedlich um da ohne größeren Aufwand Schlüsse daraus ziehen zu können. Im Endeffekt verhalten sich hier scheinbar verschiedene Flash-Versionen verschieden und fancyUpload kann nicht mit allem umgehen. Einige laufen in einen HTTP-Fehler 400 rein, die anderen nicht.

Das ist übrigens nur bedingt ein Problem von TYPOlight sondern vermutlich eher im Bereich Flash/fancyUpload zu suchen.

Jan

[aportmann]

indirekt wird es sicherlich zu einem problem von typolight, sollten sich die probleme bei anderen nutzern ebenfalls bestätigen.
das «feature» ist standardmässig aktiviert. sollte sich fancyupload wirklich so instabil verhalten, frage ich mich, wieso es verwendet wird.

warten wir ab, wie es sich entwickelt.


gruss andi

[Trikerdaniel]

Ich habe ohne Probleme das Update auf die 2.8.0 gemacht.
Ich habe nun unter OS X: Safari und Firefox und unter Win: Firefox und IE 7 +8 den Fancyupload getestet. Bei mir funktioniert es ohne Probleme!

Daniel

[aportmann]

osx-version? bin unter 10.6.2 unterwegs mit safari 4.0.4.

@moderatoren: sollte man daraus nicht einen eigenen beitrag machen? wäre super.

[Trikerdaniel]

osx-version? bin unter 10.6.2 unterwegs mit safari 4.0.4.

Ich bin auch unter OS X 10.6.2 und Safari 4.0.4 unterwegs!
Backend nicht mit .htaccess geschützt!

[alphabeet]

Bei mir gehts nicht unter Win XP Firefox 3.5.7 und WIN XP IE 7 (.irgendwas)

Mein Workaround: ich lade per FTP rauf. Kann mir das später Probleme einbringen? Z.B. Datei irgendwo nicht angemeldet oder so ähnlich?

[oli_lu]

Hallo,

ich habe auch Probleme mit dem Upload unter OSX 10.6.2 und Safari, als auch unter XP SP3 und Firefox 3.6.

Nachtrag:
Ich habe eben auf das neuste Flash-Plugin upgedatet. Leider ohne Ergebnis. deshalb habe ich vorerst den FancyUpload unter Einstellungen deaktiviert.

[Maik]

Hallo zusammen,

wurde das berücksichtigt?

FancyUpload und .htaccess

Falls Sie das TYPOlight-Backend mittels .htaccess geschützt haben, können Sie FancyUpload nicht für den Dateiupload in der TYPOlight-Dateiverwaltung nutzen, ohne eine .htaccess-Datei mit folgendem Inhalt im Backend-Verzeichnis (/typolight) zu erstellen:

<FilesMatch "upload\.php$">
Satisfy Any
Order allow,deny
Allow from all
</FilesMatch>

[leo]

Bitte unbedingt lesen: https://community.contao.org/de/showthread.php?t=4893

FancyUpload möchte eine aktuelle Flash-Version haben. Ich musste außerdem bei mir den kompletten Browser-Cache leeren, bevor es seinen Dienst tat. Die verschiedenen Error-Codes sind auf der FancyUpload-Projektwebseite beschrieben. Ein Ticket auf https://contao.org macht nur Sinn, wenn es ein TYPOlight-Fehler ist!

[Sebastian]

HI

ich habe die diversen Threads zu diesem Thema nun zusammengelegt, damit alles schön geordnet bleibt…

Sebastian

[FloB]

So, habe es jetzt erst geschafft die betroffene Installation auf r196 zu aktualisieren, et voilà, es funktioniert . Übrigens: Sehr gute Idee mit der neuen Implementierung, Leo, die ist intelligent und simpel zugleich!

[Nina]

Nach dem Update von Flash und ordentlichem Durchputzen des Firefox Caches läuft es nun auch bei mir einwandfrei.

[PA1Y]

Hallo, ich habe ein ähnliches Problem mit FancyUpload. Es wird kein HTTP-Status Code zurückgegeben.
Ich habe es mit Firefox 3.6 und Internet Explorer 8 ausprobiert.
Der Browser-Cache habe ich geleert und ich verwende keine geschützte Verzeichnis. Ich habe für die sicherheit auch der workaround ausprobiert aber ohne Erfolg.
Dies ist der Inhalt der Zugriffs-Log-Datei auf dem Server:

"GET /plugins/fancyupload/Swiff.Uploader.swf?noCache=1266756244373 HTTP/1.1" 200 7627 "http://www.bornweb.nl/typolight/main.php?do=files&act=move&mode=2&pid=tl_files/bornweb&id=" "Mozilla/5.0 (Windows; U; Windows NT 6.1; nl; rv:1.9.2) Gecko/20100115 Firefox/3.6"
"GET /plugins/fancyupload/Swiff.Uploader.swf?noCache=1266756244373 HTTP/1.1" 304 - "http://www.bornweb.nl/typolight/main.php?do=files&act=move&mode=2&pid=tl_files/bornweb&id=" "Mozilla/5.0 (Windows; U; Windows NT 6.1; nl; rv:1.9.2) Gecko/20100115 Firefox/3.6"
"POST /typolight/upload.php?do=files&act=move&mode=2&pid=tl_files/bornweb&id= HTTP/1.1" 200 61 "-" "Shockwave Flash"

Wer hat noch einen guten Tipp? Vielen Dank im Voraus.