Mit TL 2.8: Fehler beim Datei-Upload

[stefan-at-work]

aktuelle Flashreader-Version im Einsatz?

[PA1Y]

aktuelle Flashreader-Version im Einsatz?

Ja, die neuesten Flash Player 10.
Oja noch etwas: ich habe auch die "Working FancyUpload Installation" von http://digitarald.de/project/fancyupload/ ausprobiert und die gibt keine Fehlermeldung!

[Sebastian]

HI

ich habe nun nochmals in allen verfügbaren Browsern getestet.

Es tut weder in Firefox noch in Safari, Chrome oder Opera unter Mac OS 10.6.2 mit der neusten Flash-Version, noch unter Windows mit denselben Bedingungen.

Linux hat keine Probleme.

Auf der Hersteller-Seite funktionieren die Demos auf allen Systemen in allen Browsern.

Sebastian

[gHeldT]

Habe dieses Problem auch - es gibt keine Fehlermeldung aber Upload findet nicht statt. Wenn ich FancyUpload deaktiviere funktioniert der Upload.

Flash ist aktuell, habe FF 3.6 benutzt

[Anke]

Bei mir quittiert Fancy Upload den Upload-Versuch mit einem http 403 Status.

TL 2.8, FF und Flash sind aktuell, Browser-Cache ist deaktiviert.

[leo]

Ben (360fusion) hat gerade im englischen Forum berichtet, dass mod_security bei ihm der Übeltäter war.

[Anke]

Wunderbar!

Bei meinem Hoster zeigt die PHP-Info enabletes mod_security, und mit den Einträgen

SecFilterEngine Off
SecFilterScanPOST Off

in der .htaccess funktioniert FancyUpload jetzt.

VG
Anke

[gHeldT]

Wenn ich auf diese Art den mod_security auf off schalte bekomme ich sofort eine 500 Internal Server Error Meldung. Provider ist 1 u. 1

[Anke]

Vielleicht hilft dir das weiter: http://forum.wordpress-deutschland.o...dsecurity.html

[gHeldT]

Hallo Anke,

habe einfach mal auf gut Glück so eine Datei (php.ini) im root-Verzeichnis erstellt - leider macht das im Ergebnis keinen Unterschied - Wieder der 500 Internal Server Error ...

In den angegebenen Foren gibt es auch keinen Bezug auf das mod_security. Dennoch Danke für Deine Hilfe.

[PA1Y]

Wenn ich auf diese Art den mod_security auf off schalte bekomme ich sofort eine 500 Internal Server Error Meldung. Provider ist 1 u. 1

Hier auch die Veränderung mit "SecFilterEngine Off" und "SecFilterScanPOST Off" ausprobiert in .htraccess und ich krieg die gleiche 500 Fehlermeldung. Der Server ist eine dedizierter Strato Server.
Kann es vielleicht etwas zu tun haben mit der "Suhosin Patch", der auf meinem Server aktiv ist, laut der PHP info?

[Babelfisch]

Kann es vielleicht etwas zu tun haben mit der "Suhosin Patch", der auf meinem Server aktiv ist, laut der PHP info?

Suhosin ist definitiv ein Problem, da das standardmäßig die Session verschlüsselt. Ich hatte das schon mal hier beschrieben. Alle, bei denen es nicht funktioniert und Suhosin aktiv ist, sollten unbedingt mal in den Simpulationsmodus von Suhosin schalten und es damit probieren. Der Browser sollte dazu auf jeden Fall komplett neu gestartet werden, damit eine neue Session gestartet wird.

Ansonsten kann ich nur sagen, dass es bei mir unter Mac OS X 1.6.2 mit Safari 4.0.4 und Firefox problemlos funktioniert.

[PA1Y]

Entschuldigung, diese Nachricht habe ich offensichtlich übersehen. Ich versuche, dem Suhosin-Patch mit "php_flag suhosin.simulation On" in .htaccess aus zu schalten aber anscheinend lass es sich nicht einfach ausschalten. Ich suche weiter ...

[Seitengestalter]

@gHeldT: Leider weiß ich nicht, wo Du die php.ini anlegen musst - im Root-Verzeichnis nutzt sie aber mit Gewissheit nichts. Möglicherweise in Root/typolight/ ?

Gruß, Roland

[ste.fan]

Hallo zusammen,
ich habe ebenfalls einen upload Fehler in einer frischen TL 2.8.0 installation.

Komischerweise funktioniert der Fancy uploader ohne Probleme, wenn ich die Dateiverwaltung über System > Dateiverwaltung benutze.

Gehe ich allerdings über Artikel > Artikel bearbeiten > Inhaltselement bearbeiten > Ein Bild hinzufügen >Dateimanager im Pop-up Fenster öffnen
zum upload, wird der upload zwar ausgeführt, allerdings erscheint nach 100% nur das Warnsymbol, ohne eine Fehlermeldung.

Gehe ich dann zurück und will einen anderen Ordner öffnen, erhalte ich folgende Meldung:

Fehler: Umleitungsfehler
Die aufgerufene Website leitet die Anfrage so um, dass sie nie beendet werden kann.
* Dieses Problem kann manchmal auftreten, wenn Cookies deaktiviert oder abgelehnt werden.

Wie gesagt, seltsam ist, dass es beim Aufruf über System einwandfrei funktioniert. Kann mir da jemand weiterhelfen oder hat schon jemand das selbe Problem beobachtet?

[leo]

Komischerweise funktioniert der Fancy uploader ohne Probleme, wenn ich die Dateiverwaltung über System > Dateiverwaltung benutze. Gehe ich allerdings über Artikel > Artikel bearbeiten > Inhaltselement bearbeiten > Ein Bild hinzufügen >Dateimanager im Pop-up Fenster öffnen
zum upload, wird der upload zwar ausgeführt, allerdings erscheint nach 100% nur das Warnsymbol, ohne eine Fehlermeldung.

Diese Möglichkeit hatte ich gar nicht bedacht -> bitte ein Ticket eröffnen.

[gHeldT]

@gHeldT: Leider weiß ich nicht, wo Du die php.ini anlegen musst - im Root-Verzeichnis nutzt sie aber mit Gewissheit nichts. Möglicherweise in Root/typolight/ ?

Gruß, Roland

Hallo Roland,

habe die php.ini wie gesagt angelegt - keine Änderung!!

[FloB]

Suhosin ist definitiv ein Problem, da das standardmäßig die Session verschlüsselt.

Nö. Hatte an der PHP-Config nichts geändert, und nach dem Update hat FancyUpload mit denselben Suhosin-Einstellungen problemlos funktioniert.

Man sollte glaube ich allgemein darauf achten, dass man aktuelle Versionen von Flash und Browser nutzt.

[Babelfisch]

Nö.

Doch. Suhosin kann je nach Einstellungen die Session noch mal extra verschlüsseln. Dazu wird ein extra Key als Cookie mitgeführt und der kann in TL nicht gesetzt werden.

Hatte an der PHP-Config nichts geändert, und nach dem Update hat FancyUpload mit denselben Suhosin-Einstellungen problemlos funktioniert.

Welches Update?

Man sollte glaube ich allgemein darauf achten, dass man aktuelle Versionen von Flash und Browser nutzt.

Daran liegt es auch nicht. Der Bug in Flash ist schon seit Version 8 bekannt und von Adobe bisher auch in der neusten Version nicht behoben. Je nach OS und Browser werden mal Cookies durch das Plugin übertragen und mal nicht, was man in den Bugreports nachlesen und auch selber testen kann.

[FloB]

Doch. Suhosin kann je nach Einstellungen die Session noch mal extra verschlüsseln. Dazu wird ein extra Key als Cookie mitgeführt und der kann in TL nicht gesetzt werden.

Ich bestreite nicht, dass Suhosin Daten verschlüsselt, ich bestreite nur, dass das Problem auf Suhosin zurückzuführen ist. Bei mir klappte die alte Version wie gesagt nicht, die neue jedoch schon, ohne dass die Konfiguration des Servers in irgendeiner Weise geändert wurde.

Welches Update?

Irgendeine Revision vor 2.8 Final auf die Final.

Daran liegt es auch nicht. Der Bug in Flash ist schon seit Version 8 bekannt und von Adobe bisher auch in der neusten Version nicht behoben. Je nach OS und Browser werden mal Cookies durch das Plugin übertragen und mal nicht, was man in den Bugreports nachlesen und auch selber testen kann.

Inzwischen sendet TL die Cookies (bzw. Session-ID) per GET-Header und setzt die Daten in der upload.php neu.

[Babelfisch]

Ich bestreite nicht, dass Suhosin Daten verschlüsselt, ich bestreite nur, dass das Problem auf Suhosin zurückzuführen ist.

Suhosin muss kein generelles Problem sein. Ich hatte mich halt nur mal in Suhosin eingearbeitet und in den Standardeinstellungen wird da eben die Session verschlüsselt, was definitiv ein Problem darstellt. Vielleicht hat dein Hoster oder du (falls du den Server selber eingerichtet hast) diese Standardeinstellungen entschärft, sodass die Session nicht verschlüsselt wird.

Inzwischen sendet TL die Cookies (bzw. Session-ID) per GET-Header und setzt die Daten in der upload.php neu.

Das war schon bei meinem ersten hier geposteten Workaround so. Leo hat das ganze „nur“ deutlich eleganter umgesetzt und noch zusätzliche Sicherheitschecks eingebaut. Das Prinzip ist aber das gleiche wie in dem allerersten Lösungsvorschlag. Deshalb wundert es mich etwas, warum jetzt auf einmal läuft. Kann es evtl. damit zusammenhängen?

[Babelfisch]

Diese Möglichkeit hatte ich gar nicht bedacht -> bitte ein Ticket eröffnen.

Done.

[FloB]

Suhosin muss kein generelles Problem sein. Ich hatte mich halt nur mal in Suhosin eingearbeitet und in den Standardeinstellungen wird da eben die Session verschlüsselt, was definitiv ein Problem darstellt. Vielleicht hat dein Hoster oder du (falls du den Server selber eingerichtet hast) diese Standardeinstellungen entschärft, sodass die Session nicht verschlüsselt wird.

Nein, definitiv nicht definitv ein Problem . Es kann höchstens sein, es muss aber nicht.
Ich nutze das Standard-Debian-Lenny-Paket, habe sogar eher die Suhosin-Einstellungen noch verschärft!

Deshalb wundert es mich etwas, warum jetzt auf einmal läuft. Kann es evtl. damit zusammenhängen?

Nein, damit hängt es auch nicht zusammen.

[Babelfisch]

Nein, definitiv nicht definitv ein Problem . Es kann höchstens sein, es muss aber nicht.

Deshalb schrieb ich ja auch:

Suhosin muss kein generelles Problem sein.

[FloB]

Lesen sollte man können

Edit: Halt nein, du hattest geschrieben, dass die Session-Verschlüsselung definitv ein Problem ist. Dem ist aber nicht so.

[Babelfisch]

Edit: Halt nein, du hattest geschrieben, dass die Session-Verschlüsselung definitv ein Problem ist. Dem ist aber nicht so.

Du bist dir ganz sicher, dass Suhosin bei dir so konfiguriert ist, dass die Session mittels Cookie verschlüsselt wird, also suhosin.session.encrypt=On und suhosin.cookie.encrypt=On sind? Wenn das so ist und es bei dir damit funktioniert, hab ich keine Ahnung, wie das technisch gehen soll.

[FloB]

Session-Encrypt ja, Cookie-Encrypt nein.

Technisch geht das problemlos: Die Daten werden "nur" verschlüsselt auf der Festplatte gespeichert. Sobald der Interpreter auf die Datei zugreift, wird diese entschlüsselt. Selbiges bei den Cookies: Sobald der PHP-Interpreter mit denen in Kontakt kommt, werden diese entschlüsselt. Die Verschlüsselung läuft vollautomatisch, der Interpreter bekommt das nur indirekt mit (Suhosin kümmert sich darum). Die Daten sind also nur in ihrer gespeicherten Form geschützt, im Arbeitsspeicher liegen sie (in der Regel) ungeschützt.

Folglich sollten diese Optionen gar keinen Einfluss auf die Funktion von PHP / TL haben.

[Babelfisch]

Session-Encrypt ja, Cookie-Encrypt nein.

Dachte ich mir doch.

Technisch geht das problemlos: …
Folglich sollten diese Optionen gar keinen Einfluss auf die Funktion von PHP / TL haben.

Nein, das geht technisch nicht problemlos. Mit Cookie-Encrypt wird nämlich ein extra Key als Cookie mitgeführt und die Session über diesen Key entschlüsselt. Da der Cookie aber wegen dem Bug im Flash-Plugin nicht übertragen wird, kann die Session folglich nicht entschlüsselt werden und PHP kommt nicht an die ursprünglichen Session-Daten. Das lässt sich durch den Workaround in TL auch nicht umgehen.

[FloB]

Mit Cookie-Encrypt wird nämlich ein extra Key als Cookie mitgeführt und die Session über diesen Key entschlüsselt.

Das war mir nicht bekannt. Steht das irgendwo? Welche Infos sind in diesem Cookie gespeichert? Sicher nicht der Key.

[Babelfisch]

Ist jetzt auch schon wieder ein paar Tage her, dass ich mir das mal genauer angeschaut habe. Wenn ich es noch richtig in Erinnerung habe, sehe ich zwei potentielle Probleme mit Suhosin, die in Verbindung mit dem fehlerhaften Flash-Plugin den Workaround in TL blockieren können:

1. Die Session Verschlüsselung: Suhosin verschlüsselt die Session-Daten auf dem Server mittels eines vorgegebenen Keys. Zusätzlich zu dem Key kann zur Verschlüsselung noch der User-Agent und die IP-Adresse des Clients genutzt werden. Da sich der User-Agent ändert (erst der Browser, dann das Flash-Plugin), kann hier bei entsprechenden Einstellungen das Entschlüsseln der Session schief gehen.

2. Suhosin kann Cookies verschlüsseln und dabei zusätzlich zu einem Key auch wieder UA und IP nutzen. Das Problem ist hierbei aber, dass die Session-ID verschlüsselt gesendet wird und im Normalfall von Suhosin entschlüsselt wird, bevor die Session gestartet wird. Da der Workaround aber die Session-ID in den POST-Daten mitgibt und daraus die Session gestartet wird, kann eine falsche – nämlich die noch verschlüsselte – Session-ID übergeben werden. Damit kann dann natürlich nicht mehr die richtige Session gestartet werden.

Ich kann es hier jetzt nicht testet aber bei beiden Punkten sehe ich arge Probleme.

[FloB]

Punkt 2 kann in TL bei der aktuellen Implementierung IMO gar nicht auftreten: Die Session ID, die per POST übergeben wird, wird ja direkt eingegeben (ich glaube per session_id() abgefragt) und nicht der Umweg über das Cookie genommen. Demzufolge wird beim FancyUpload die Suhosin-Cookie-Encryption umgangen, somit wird weder etwas verschlüsselt, noch muss etwas entschüsselt werden.

Der Einwand bei Punkt 1 ist jedoch gerechtfertigt, wenn er stimmt. In meinen Einstellungen ist aber sowohl Session-Encrypt als auch Session-CryptUA aktiviert, somit sollte es nicht daran liegen.
Dennoch: Bei denjenigen, bei denen FU noch nicht funktioniert und Suhosin einsetzen, sollten mal prüfen, ob nach deaktivieren von suhosin.session.cryptua der Upload doch funktioniert.

[uweh..]

Hallo,

geht denn jetzt bei allen der Datei-Upload in der Version 2.8.1? Ich kriege es bei 1und1 unter mehreren Domains nicht ans laufen.

Die Online-Demo meldet mir keine Fehler, allerdings kommt dort verständlicherweise keine Datei im Verzeichnis an.

Gruß Uwe

[PA1Y]

Bei mir funktioniert die FancyUpload auch nicht unter TL 2.8.1.
Die Suhosin Patch kann ich nicht einfach ausschalten. Der Server ist openSUSE 11.1 + Apache 2.2.10 + PHP 5.2.11 und hat suhosin integriert.
Die letzte Option ist, um zu versuchen die Suhosin Patch vollständig vom Server zu löschen, aber das mach ich lieber nicht.
Kein großes Problem, weil zum Glück die Standard Upload-Funktion immer noch vorhanden ist.

[FloB]

Und wieder die Standardfrage: Flash-Version, Browser? TYPOlight-Check durchgeführt?

666. Post ^^

[PA1Y]

Und wieder die Standardfrage: Flash-Version, Browser? TYPOlight-Check durchgeführt?

Blick ein wenig höher:

Ich habe es mit Firefox 3.6 und Internet Explorer 8 ausprobiert.

die neuesten Flash Player 10.

TYPOlight-Check durchgeführt?

Ja, und alles ist grün.
Das Problem ist fast sicher das Suhosin Patch.

[Babelfisch]

Die letzte Option ist, um zu versuchen die Suhosin Patch vollständig vom Server zu löschen, aber das mach ich lieber nicht.

Suhosin einfach mal in den Simulationsmodus schalten, ist sicherlich einfacher.

Also entweder in der .htaccess schreiben:

php_flag suhosin.simulation on

oder in der php.ini:

[suhosin-ext]
suhosin.simulation=”On”

Eine suhosin.ini könnte es auch noch geben, wo das auch eingetragen werden kann.

[PA1Y]

Die Suhosin Patch kann ich nicht einfach ausschalten. Der Server ist openSUSE 11.1 + Apache 2.2.10 + PHP 5.2.11 und hat suhosin integriert.

Also die vorgeschlagen lösungen funktionieren allen nicht, die hab ich schon alle ausprobiert.

[Babelfisch]

Die Suhosin Patch kann ich nicht einfach ausschalten. Der Server ist openSUSE 11.1 + Apache 2.2.10 + PHP 5.2.11 und hat suhosin integriert.

Wieso kannst du Suhosin nicht ausschalten? Auch wenn der Patch integriert ist, wir es sich ja wohl trotzdem ganz normal konfigurieren lassen.

Also die vorgeschlagen lösungen funktionieren allen nicht, die hab ich schon alle ausprobiert.

Webserver neu gestartet? Richtige php.ini gefunden (da gibt es meist mehr als eine bei SUSE?

[uweh..]

Hallo,

ich habe auch alles aktualisiert und es steht alles auf "grün". Wenn ich

php_flag suhosin.simulation on

in die .htaccess eintrage, kommt direkt vom Apache ein 500er Fehler.

Getestet mit IE 8, Firefox 3.6, aktuellem Flash. Wo ist denn bei 1und1 die richtige php.ini zu finden, komme ich da überhaupt ran? Im root des Webverzeichnisses hat sie jedenfalls keine Auswirkung.

Gruß Uwe

[Babelfisch]

Da kannst du nur bei 1und1 direkt nachfragen.