Druckbare Version
Hallo,
ich habe mit der 2.8.RC2 das gleiche Problem.
Wie kann ich den Fancy Upload sauber deaktivieren?
Bisher hätte ich dazu tendiert, die ensprechenden Dateien aus dem Plugin-Ordner zu löschen. Den Fancy Upload braucht es m.E. für den Normalbetrieb nicht...
LG
Erst in einem Build nach RC2 gibt es eine Option, FancyUpload zu deaktivieren. Bis dahin könnte(!) es reichen den Ordner zu löschen.
Ich hab mir das mal angeschaut und in einem neuen Ticket einen Lösungsvorschlag zu dem Problem geschrieben. Bei mir funktioniert der fancyUpload damit jetzt tadellos.
Vielleicht könnt ihr es auch mal testen und schreiben, ob es auch bei euch damit klappt.
Gruß
Hallo netspy,
das werde ich mal testen.
Kann es evtl. primär mit der installieren Fash Version zusammenhängen?
Wenn ich mich richtig erinnere, tritt das Problem bei mir auf, seit ich die Flash CS4 installeirt habe...
Evtl. gibt es auch ein Problem mit dem Flashplayer 10? Joomla! 1.5 hat mit dem Flash Player 10 auch Probleme mit dem Dateiupload.
LG
hangover
Ich vermute auch, dass es mit dem jeweiligen Flash-Plugin zusammenhängt und habe auch Adobe CS4 in Verdacht. Ist bei mir ebenfalls installiert und das tauscht Flash auf jeden Fall aus.
Schreib mal, ob es mit den Änderungen funktioniert. Die Codestellen sollten sich auch im RC2 leicht finden lassen, falls du nicht mit dem aktuellen Trunk arbeitest. Wenn nicht, schreib noch mal und ich schaue mal nach, welche Zeilen das im RC2 sind.
Ich hatte nie CS4 installiert.
Im RC2 gibt es die fancyUpload.php noch nicht (erst ab Revision 141), davor befindet sich der Code in der DC_Folder.php.Zitat:
Zitat von netspy
Ich packe grade eine Version und teste es mal bei mir.
Hat jemand ClickToFlash installiert? Das wäre auch noch ein möglicher Problemkandidat, wobei ich das nicht glaube.
Unabhängig davon hoffe ich, dass Leo den Patch trotzdem einbaut, da damit solche Probleme unabhängig vom Flash-Plugin umgangen werden können.
HI
ich habe mal auf dem Fedora-Server den neusten Nightly-Build getestet, und in der Tat tritt das Problem immer noch auf. :(
Wenn ich FancyUpload deaktivere (danke Leo!), tut immerhin der alte Upload, aber das ist natürlich nicht Sinn der Sache :)
Ich werde mal noch netspys Vorschlag testen…
Sebastian
Mit dem Server hat es mit ziemlicher Sicherheit nichts zu tun. Die Cookies werden definitiv nicht übertragen und dadurch kann die Session nicht gestartet werden, weshalb der Upload von TL geblockt wird.
Mit neustem Nightly und deiner Änderung (BTW: im Ticket hast du im JS ein Klammer-zu sowie Komma vergessen) funktionierts leider immernoch nicht. Session-ID wird laut Log zwar übergeben, aber das Session-Array bleibt trotzdem leer.
An alle, bei denen es (noch?) nicht funktioniert: Wie ist PHP bei euch konfiguriert? Mit Suhosin?
Danke für den Hinweis wegen der fehlenden Zeichen, hab es im Ticket ergänzt.
Hast du die Session in der upload.php getestet? Dort ist $_SESSION auf jeden Fall noch leer, da es erst mit session_start() gefüllt wird. Wenn du also die Session testen willst, musst du hinter das session_id($_GET[session_name()]); in der upload.php noch die Session starten, dann ist $_SESSION auch gefüllt. Zum Upload ist das jedoch nicht nötig, da die Session später noch in TL gestartet wird und es nur wichtig ist, dass die Session-ID aus der URL genommen wird.
Schon klar :)Zitat:
Zitat von netspy
Nö ;)Zitat:
Zitat von netspy
Und in $_GET[session_name()] steht die Session-ID drin? Dann sollte die Session auch mit…
… gestartet werden. Wenn nicht … :(PHP-Code:session_id($_GET[session_name()]);
session_start();
In diesem Fall können wir uns wohl den Workaround sparen, da er das Problem offenbar auch nicht behebt. Der Vollständigkeit halber aber die Frage, wieso Du session_id($_GET[session_name()]) aufrufst. Sofern die Variable mit dem PHP-Session-Bezeichner (in der Regel PHPSESSID) übergeben wird, sollte session_start() das doch erkennen, oder?Zitat:
Zitat von FloB
Also bei mir funktioniert es mit dem Patch hervorragend, sonst hätte ich ihn nicht gepostet. Mir ist auch nicht klar, warum es bei FloB nicht funktioniert. Mit dem Patch sollte die Session-ID unter jeder denkbaren Konfiguration und unabhängig von Cookies übertragen und richtig gesetzt werden.Zitat:
Zitat von leo
Das hängt vermutlich von der PHP-Konfiguration ab. Bei mir ging es erst mit dem expliziten Aufruf mit der Session-ID.Zitat:
Zitat von leo
Noch ein Aspekt dazu: http://de3.php.net/manual/de/function.session-start.php
Da TYPOlight ob_gzhandler jedoch erst im Template kurz vor der Ausgabe aufruft, ist diese Bedingung nicht erfüllt. Eventuell hilft also erstmal das Abschalten der gzip-Kompression?Zitat:
Verwendet ein Benutzer ob_gzhandler oder ähnliches mit ob_start(), ist die Reihenfolge der Augaberoutine wichtig für eine korrekte Ausgabe. Zum Beispiel muss der Benutzer ob_gzhandler vor Beginn der Session registrieren.
Die gzip-Kompression habe ich nicht an, daran kann es nicht liegen.
Wie schon gesagt, ergibt sich das Problem daraus, dass im Request des fancyUploads keine Cookies übergeben werden ($_COOKIE ist ein leeres Array). Daher kann die Session nicht gestartet werden und der Upload wird wegen des fehlgeschlagenen FANCY_KEY-Vergleichs mit einem 400er Status abgebrochen.
Mein Patch macht nichts weiter, als die Session-ID in der URL des Requests mit zu übergeben (übrigens ein Tipps von der fancyUpload-Seite) und PHP dann zu sagen, dass es die Session später mit der übergebenen Session-ID starten soll. Mehr ist das nicht.
Das Problem ist übrigens nicht auf PHP und TL beschränkt. Auch in Python ist schon mal jemand darüber gestolpert und hat eine ähnliche Lösung dafür:
http://www.stereoplex.com/2007/nov/7...tication-with/
Es ist ja schön, dass Du für Dich eine Lösung gefunden hast. Wir suchen hier aber eine Lösung, die auf allen Systemen funktioniert und nicht nur auf Deinem :(
Ich hab gestern einige Stunden über diesem nicht ganz so trivialen Problem gesessen und denke, dass der Lösungsvorschlag auf allen Systemen funktioniert (sonst hätte ich es wohl auch kaum gepostet). Bisher hat es soweit ich das sehe nur ein Nutzer getestet und da kam auch noch keine Rückmeldung auf meine Frage. Möglicherweise hat FloB ja auch noch irgendwas nicht geändert (bspw. den Test von 5 auf 6 Parameter) und es liegt daran. Wenn nicht, muss halt weitergesucht werden.Zitat:
Zitat von leo
Wenn jemand einen besseren Vorschlag hat, kann er ihn ja gerne hier schreiben. Ich kann nur sagen, dass das Problem definitiv an nicht übertragenen Cookies liegt und das meine Lösung theoretisch das Problem auf allen System lösen sollte. Auf 3 verschiedenen Testsystemen (zwei mal Linux und ein mal MAMP) mit PHP 5.2.x und PHP 5.3.x funktioniert es mit meinen Änderungen auf jeden Fall in Safari und Firefox. Das will noch nichts heißen, ist aber sicherlich schon mal ein Anfang.
Hatte ich geändert. Laut Logs kam ich wieder bis zur Referer- / Fancykey-Abfrage in der initialize.php.Zitat:
Zitat von netspy
Ich muss nochmal genauere Tests fahren, kann aber ein paar Tage dauern, da ich unterwegs bin.
Der Hinweis mit dem GZip ist interessant – ich habe das bei mir nämlich immer aktiviert.
Kommando zurück – GZip war gar nicht aktiviert. Habe nochmal ein Logging kurz vor der Referer-Kontrolle eingebaut (somit nachdem die Session gestartet wurde – Edit: Zeile 152), und das Array bleibt (bei FancyUploads) leer.
Nochmal meine Frage: Ist bei denen, bei denen FancyUpload nicht funktioniert, zufällig Suhosin aktiviert?
Hast du denn mal die Referer-Prüfung testweise deaktiviert?Zitat:
Zitat von FloB
Suhosin ist bei mir nicht installiert. Das könnte aber natürlich schon Einfluss haben und für weitere Probleme verantwortlich sein.Zitat:
Zitat von FloB
@FloB: Kannst du bei dir mal testweise suhosin.session.encrypt auf Off stellen? Ich hab mir mal Suhosin angesehen und habe stark das Session Protection System in Verdacht, weswegen der Patch bei dir nicht funktioniert und die Session nicht gestartet wird.
@all: Wäre schön, wenn dass noch mal jemand anders ohne Suhosin testen könnte. Bitte beim Ticket den letzten Eintrag beachten! Bei einer Quellcodezeile hatte ich zwei Zeichen am Ende vergessen.
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.
Anyways, ich probier es mal bei Gelegenheit aus.
Edit: Ja, Referer hatte ich mal deaktiviert (dann kommt es ja gar nicht erst zur FANCY_KEY-Überprüfung). Da kam ich erstmal durch die Prüfung (jedoch hab ich iwo noch ein anderes Problem mit dem FancyUpload).
Ich glaube nicht, dass das egal ist. Ich weiß nicht genau, was Suhosin im Einzelnen macht aber wenn die Entschlüsselung vielleicht noch einen zusätzlichen Cookie benötigt, dann wird der ja nicht übertragen und die Session kann trotz der Session-ID nicht gestartet werden. Setzte Suhosin doch einfach mal in den Simulationsmodus (suhosin.simulation = On) und schau nach, ob es damit funktioniert. Ich kann mir ansonsten nicht erklären, warum es bei dir nicht funktioniert.Zitat:
Zitat von FloB
BTW: Im Ticket habe ich es schon geschrieben, das Problem ergibt sich aus einem schon seit Jahren bekannten Bug in Flash, der Adobe offenbar nicht interessiert. :mad:
Hallo netspy,
ich nutze auf einem Server bei All-Inkl nur den Suhosi Patch und nicht die Extention, das Problem tritt aber trotzdem auf.
Was ist der Unterschied zwischen dem Patch und der Extension? Das Ergebnis ist doch sicherlich das gleiche.Zitat:
Zitat von hangover
Schreib doch mal testweise folgendes in die .htaccess von TYPOlight:
Ich weißt zwar nicht genau, ob sich Suhosi auch in der .htaccess konfigurieren lässt aber eigentlich sollte es gehen.Code:php_flag suhosin.simulation On
Ich hab neben Suhosin einen weiteren Kandidaten für das Problem gefunden: session.auto_start. Ist das bei euch evtl. auf On? Damit geht es dann auch nicht, da die Session ja schon gestartet wird, ehe die richtige Session-ID übergeben wird. Am besten mal in der php.ini mit:
oder in der .htaccess mit:Code:session.auto_start = Off
deaktivieren.Code:php_value session.auto_start 0
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!
Eine sehr konkrete Problembeschreibung :)Zitat:
Zitat von Sebastian
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