aktuelle Flashreader-Version im Einsatz?
Druckbare Version
aktuelle Flashreader-Version im Einsatz?
Ja, die neuesten Flash Player 10.Zitat:
Zitat von stefan-at-work
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
in der .htaccess funktioniert FancyUpload jetzt.Code:SecFilterEngine Off
SecFilterScanPOST Off
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. :)
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.Zitat:
Zitat von gHeldT
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.Zitat:
Zitat von PA1Y
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:
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:
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.
Diese Möglichkeit hatte ich gar nicht bedacht :mad: -> bitte ein Ticket eröffnen.Zitat:
Zitat von ste.fan
Hallo Roland,Zitat:
Zitat von Seitengestalter
habe die php.ini wie gesagt angelegt - keine Änderung!!
Nö. Hatte an der PHP-Config nichts geändert, und nach dem Update hat FancyUpload mit denselben Suhosin-Einstellungen problemlos funktioniert.Zitat:
Zitat von netspy
Man sollte glaube ich allgemein darauf achten, dass man aktuelle Versionen von Flash und Browser nutzt.
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
Welches Update?Zitat:
Zitat von FloB
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 FloB
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
Irgendeine Revision vor 2.8 Final auf die Final.Zitat:
Zitat von netspy
Inzwischen sendet TL die Cookies (bzw. Session-ID) per GET-Header und setzt die Daten in der upload.php neu.Zitat:
Zitat von netspy
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.Zitat:
Zitat von FloB
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?Zitat:
Zitat von FloB
Done.Zitat:
Zitat von leo
Nein, definitiv nicht definitv ein Problem ;). Es kann höchstens sein, es muss aber nicht.Zitat:
Zitat von netspy
Ich nutze das Standard-Debian-Lenny-Paket, habe sogar eher die Suhosin-Einstellungen noch verschärft!
Nein, damit hängt es auch nicht zusammen.Zitat:
Zitat von netspy
Deshalb schrieb ich ja auch:Zitat:
Zitat von FloB
Zitat:
Suhosin muss kein generelles Problem sein.
Lesen sollte man können :rolleyes:
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.Zitat:
Zitat von 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.
Dachte ich mir doch. ;)Zitat:
Zitat von FloB
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.Zitat:
Zitat von FloB
Das war mir nicht bekannt. Steht das irgendwo? Welche Infos sind in diesem Cookie gespeichert? Sicher nicht der Key.Zitat:
Zitat von netspy
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.
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.
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
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.
Und wieder die Standardfrage: Flash-Version, Browser? TYPOlight-Check durchgeführt?
666. Post ^^
Blick ein wenig höher:Zitat:
Zitat von FloB
Zitat:
Zitat von PA1Y
Zitat:
Zitat von PA1Y
Ja, und alles ist grün.Zitat:
Zitat von FloB
Das Problem ist fast sicher das Suhosin Patch.
Suhosin einfach mal in den Simulationsmodus schalten, ist sicherlich einfacher. ;)Zitat:
Zitat von PA1Y
Also entweder in der .htaccess schreiben:
oder in der php.ini:Code:php_flag suhosin.simulation on
Eine suhosin.ini könnte es auch noch geben, wo das auch eingetragen werden kann.Code:[suhosin-ext]
suhosin.simulation=”On”
Also die vorgeschlagen lösungen funktionieren allen nicht, die hab ich schon alle ausprobiert. :(Zitat:
Zitat von PA1Y
Wieso kannst du Suhosin nicht ausschalten? Auch wenn der Patch integriert ist, wir es sich ja wohl trotzdem ganz normal konfigurieren lassen.Zitat:
Zitat von PA1Y
Webserver neu gestartet? Richtige php.ini gefunden (da gibt es meist mehr als eine bei SUSE?Zitat:
Zitat von PA1Y
Hallo,
ich habe auch alles aktualisiert und es steht alles auf "grün". Wenn ich
in die .htaccess eintrage, kommt direkt vom Apache ein 500er Fehler.Code:php_flag suhosin.simulation on
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
Da kannst du nur bei 1und1 direkt nachfragen.