Mit TL 2.8: Fehler beim Datei-Upload

Hallo netspy,

ich habe gerade Deinen Workaround ausprobiert. Dadurch verschwindet bei mir zwar die FancyUpload Maske (liegt wohl an meiner ältern Version) der Upload mit der alten Anischt funktioniert damit aber wieder einwandfrei...

Alte Zeile DC_Folder.php
url: $("'.$this->strTable.'").action.replace("main.php", "upload.php"),

Neue Zeile DC_Folder.php
url: $("<?php echo $this->strTable; ?>").action.replace("<?php echo basename($this->Environment->script); ?>?","upload.php?<?php echo session_name(); ?>=<?php echo session_id(); ?>&"),


Soweit ich weiß, ist der Patch von Suhosin nur eine abgespeckte Version, bei welcher die Option suhosin.session.encrypt Off gar nicht greift.

Hallo hangover,

hast du auch die zwei Änderungen in der upload.php gemacht? Die sind auf jeden Fall notwendig.

Zu Suhosin, ich denke jetzt auch, dass es vermutlich nicht schuldig ist. Vielmehr ist es wohl eher session.auto_start. Zumindest kann ich es bei mir damit nachvollziehen. Wenn session.auto_start an ist, dann greift der Workaround nicht mehr, da die Session schon gestartet ist. Soweit ich das sehe geht es auch nicht anders, als session.auto_start zu deaktivieren (was auch Standardeinstellung in PHP ist). Schau doch mal nach, ob das bei dir an ist.

Gruß

Hallo netspy,

ich werde mir die PHP Einstellungen zum Sessionmanagement gleich mal genauer ansehen.

Die upload.php habe ich natürlich entsprechend angepasst:

@session_id($_GET[session_name()]);
if (count($_GET) != 6 || empty($_POST))
{
...
}

Das Problem muss wohl in den unterschiedlichen Revisions (DC_Folder.php / fancyUpload.php) liegen.

Ich habe die Implementierung noch mal grundlegen überarbeitet und alles rausgenommen, was eventuelle Inkompatibilitäten verursachen könnte (siehe r170/r171). Die dank FancyUpload über POST statt über COOKIE gesendeten Daten werden jetzt manuell an die richtige Stelle kopiert, so dass die Anfrage zum Zeitpunkt der Einbindung der main.php wie jede andere TYPOlight-Anfrage aussieht. Damit sollte jeder Request, der es bis zur upload.php schafft, auch durch TYPOlight kommen.

An gzip lag es bei mir nicht. Suhosin hatte ich nie und es hatte trotzdem nicht funktioniert. Wie gesagt kann ich die workarounds im Moment nicht testen, da es bei mir ja wie aus heiterem Himmel wieder funktionierte.

Andreas

HI

leider funktioniert es bei mir weder mit Revision 170 noch mit 171 :(

Aber danke Leo für den Versuch, und vor allem für die Möglichkeit, FancyUpload zu deaktiveren! :)

Sebastian

PS: Oh, die Versionsnummer hat sich geändert… Ich freue mich!

Zitat:

---

Zitat von Sebastian

leider funktioniert es bei mir weder mit Revision 170 noch mit 171 :(

---

Eine sehr konkrete Problembeschreibung :)

HI

entschuldigung. Ich wollte nur sagen, dass sich bei mir nichts geändert hat. Es kommt immer noch ein Fehler #400 zurück :(

Am Wochenende kann ich mal versuchen, netspys und FloBs Code-Tricks nachzuvollziehen, aber im Moment reicht es nur für das Einspielen von Nightly Builds.

Ich verrate dir gerne auch mehr, aber ich wüsste im Moment nicht was :)

Sebastian

@Leo: Danke, mit r171 funktioniert es jetzt prima.

@Sebastian: Hast du mal nachgeschaut, ob bei dir session.auto_start an ist? Wenn ja, deaktiviere es mal, da es damit nicht gehen kann.

HI

in der php.ini steht: session.auto_start = 0

Sebastian

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

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 …

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

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?

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

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?

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

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?

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

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

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

Zitat:

---

Zitat von netspy

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

---

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?

Zitat:

---

Zitat von leo

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.

Zitat:

---

Zitat von FloB

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?

Zitat:

---

Zitat von netspy

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.

Zitat:

---

Zitat von netspy

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

Zitat:

---

Zitat von leo

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.

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

Zitat:

---

Zitat von leo

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.

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

HI

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

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

HI

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

Sebastian

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.

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

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:

Code:

---

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

---

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

@ alphabeet
Auch bei mir geht der Upload nicht mehr.

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

Zitat:

---

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?

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.

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

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

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

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

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.

Zitat:

---

Zitat von andi

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!

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?

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.

Hallo zusammen,

wurde das berücksichtigt?

Zitat:

---

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:

Code:

---

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

---

---

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!

HI

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

Sebastian

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!

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

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:

Code:

---

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

aktuelle Flashreader-Version im Einsatz?

Zitat:

---

Zitat von stefan-at-work

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! :eek:

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

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

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.

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

Wunderbar!

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

Code:

---

SecFilterEngine Off
SecFilterScanPOST Off

---

in der .htaccess funktioniert FancyUpload jetzt.

VG
Anke

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

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

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

Zitat:

---

Zitat von 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

---

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?

Zitat:

---

Zitat von PA1Y

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.

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

@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 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:

Zitat:

---

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?

Zitat:

---

Zitat von ste.fan

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 :mad: -> bitte ein Ticket eröffnen.

Zitat:

---

Zitat von 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

---

Hallo Roland,

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

Zitat:

---

Zitat von netspy

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.

Zitat:

---

Zitat von FloB

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.

Zitat:

---

Zitat von FloB

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

---

Welches Update?

Zitat:

---

Zitat von FloB

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.

Zitat:

---

Zitat von netspy

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.

Zitat:

---

Zitat von netspy

Welches Update?

---

Irgendeine Revision vor 2.8 Final auf die Final.

Zitat:

---

Zitat von netspy

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.