aktuelle Flashreader-Version im Einsatz?
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!
Geändert von PA1Y (21.02.2010 um 13:15 Uhr)
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.
Kann es vielleicht etwas zu tun haben mit der "Suhosin Patch", der auf meinem Server aktiv ist, laut der PHP info?
Geändert von PA1Y (23.02.2010 um 17:32 Uhr)
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.
Meine aktiven Contao-Projekte: Lingolia • Stiftung firmm
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
Wenn Null besonders groß ist, ist es fast so groß wie ein bisschen Eins.
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?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 -> bitte ein Ticket eröffnen.
So long,
FloB since Nov. 2007 +706P +115P and counting
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.
Welches Update?
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.
Meine aktiven Contao-Projekte: Lingolia • Stiftung firmm
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.
Irgendeine Revision vor 2.8 Final auf die Final.
Inzwischen sendet TL die Cookies (bzw. Session-ID) per GET-Header und setzt die Daten in der upload.php neu.
So long,
FloB since Nov. 2007 +706P +115P and counting
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.
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?
Meine aktiven Contao-Projekte: Lingolia • Stiftung firmm
Done.
Meine aktiven Contao-Projekte: Lingolia • Stiftung firmm
So long,
FloB since Nov. 2007 +706P +115P and counting
Meine aktiven Contao-Projekte: Lingolia • Stiftung firmm
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.
So long,
FloB since Nov. 2007 +706P +115P and counting
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.
Meine aktiven Contao-Projekte: Lingolia • Stiftung firmm
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.
So long,
FloB since Nov. 2007 +706P +115P and counting
Dachte ich mir doch.
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.
Meine aktiven Contao-Projekte: Lingolia • Stiftung firmm
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.
Meine aktiven Contao-Projekte: Lingolia • Stiftung firmm
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.
So long,
FloB since Nov. 2007 +706P +115P and counting
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 ^^
So long,
FloB since Nov. 2007 +706P +115P and counting
Suhosin einfach mal in den Simulationsmodus schalten, ist sicherlich einfacher.
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”
Meine aktiven Contao-Projekte: Lingolia • Stiftung firmm
Meine aktiven Contao-Projekte: Lingolia • Stiftung firmm
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.
Meine aktiven Contao-Projekte: Lingolia • Stiftung firmm
Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
Lesezeichen