Mit TL 2.8: Fehler beim Datei-Upload

Zitat:

---

Zitat von FloB

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.

Zitat:

---

Zitat von FloB

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?

Zitat:

---

Zitat von leo

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

---

Done.

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.

---

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!

Zitat:

---

Zitat von netspy

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.

Zitat:

---

Zitat von FloB

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

---

Deshalb schrieb ich ja auch:

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.

Zitat:

---

Zitat von FloB

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.

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.

Zitat:

---

Zitat von FloB

Session-Encrypt ja, Cookie-Encrypt nein.

---

Dachte ich mir doch. ;)

Zitat:

---

Zitat von FloB

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.

Zitat:

---

Zitat von netspy

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.

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

Zitat:

---

Zitat von FloB

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

---

Blick ein wenig höher:

Zitat:

---

Zitat von PA1Y

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

---

Zitat:

---

Zitat von PA1Y

die neuesten Flash Player 10.

---

Zitat:

---

Zitat von FloB

TYPOlight-Check durchgeführt?

---

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

Zitat:

---

Zitat von PA1Y

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:

Code:

---

php_flag suhosin.simulation on

---

oder in der php.ini:

Code:

---

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

---

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

Zitat:

---

Zitat von 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. :(

Zitat:

---

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

---

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

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?

Hallo,

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

Code:

---

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

Da kannst du nur bei 1und1 direkt nachfragen.

Auch wenn es hier vielleicht nicht hingehört, warum arbeiten fancyupload, oder fast alle jquery uploader alle mit einem flash Fenster?

weil HTML nicht dafür ausgelegt ist einen Multiupload durchzufühten deshalb braucht es da was anderes ... Flash.

Zitat:

---

Zitat von schman

weil HTML nicht dafür ausgelegt ist einen Multiupload durchzufühten deshalb braucht es da was anderes ... Flash.

---

Ja, aber mit query/mootools sollte das doch gehen?

Ich hab auch schon nach einer reinen JS-Lösung geschaut und nichts gefunden. So einfach geht es wohl doch nicht. Ich vermute mal, dass das JavaScript zu hohen Sicherheitsbeschränkungen im Browser unterliegt und keine Dateien senden kann.

Ich kann das Problem ebenfalls unter OS X 10.6.2 mit Safari 4.0.4 und Chrome 5.03 reproduzieren. Flash ist aktuell.
Allerdings kann ich noch folgendes Verhalten beobachten: Für ein Projekt benötigen wir für den internen Bereich größere Uploads. Daher habe ich die Standard-Upload-Size einfach um eine weitere 0 ergänzt, damit ich im Maximalfall bis zu 20MB schieben kann. Bei Dateien unterhalb von 1-2MB geht alles glatt. Bei Dateien zwischen 2-15MB bekomme ich die Meldung, dass die Dateien zu groß seien!! (20,5MB maximum). Bei Dateien, die sich an die 20MB annähern kommt dann der schon erwähnte #400er-Code.
Die Grenzen mit den Filesizes hab ich jetzt nicht aufs exakte ausgetestet, aber diese Fehler konnte ich auf zwei unabhängigen Hostern reproduzieren.
Vielleicht hilft euch das ja bei der Fehlersuche weiter.
Grüße
Markus

//EDIT: Ich bin gerade sehr verwundert. Habe eben nochmal durch meine Einstellungen geblättert und dabei ist mir aufgefallen, dass der eine Hoster den SafeMode an hatte und ich eigentlich auch den SafeMode-Hack implementiert hatte. Als ich dann in die localconfig.php gesehen hab, war dort der SafeMode-Hack (noch) nicht drin. Trotzdem konnte ich gestern rund 100 Bilder mit je zwischen 500kb-1000kb mit dem FancyUpload hochladen. Hab ich da was verpasst?
Die oben genannte Problematik mit den verschiedenen Dateigrößen bleibt aber trotz korrektem SafeModeHack weiterhin bestehen...

Zitat:

---

Zitat von markusger

Bei Dateien unterhalb von 1-2MB geht alles glatt. Bei Dateien zwischen 2-15MB bekomme ich die Meldung, dass die Dateien zu groß seien!! (20,5MB maximum).

---

Wie ist denn upload_max_filesize (siehe php.ini / phpinfo() ) eingestellt?

Wenn man in den Einstellungen die Referer-Prüfung deaktiviert, geht es.

@tgr

Das kann aber nicht die Lösung sein.
1. Wird extra in den Einstellungen darauf hingewiesen, dass nach dem deaktivieren ein potentielles Sicherheitsisiko besteht und
2. ist es bei mir so, dass in der Produktiv- und Testumgebung der Referer aktiv ist. Aber nur in der Produktivumgebung der Download nicht funktioniert.
Ich habe aber leider keinen blassen Schimmer was der Unterschied zwischen den zwei Installationen ist.

Michael

Zitat:

---

Zitat von tgr

Wenn man in den Einstellungen die Referer-Prüfung deaktiviert, geht es.

---

Nein, das reicht bei dem beschriebenen Problem nicht aus.

Gruß

ich kriege den fancyupload einfach nicht zum laufen, egal ob mac, pc, ie, safari, firefox, aktuellste flashversion, usw..

ich erhalte immer diese fehlermeldung:
Upload fehlgeschlagen: Der Server hat den HTTP-Status #406 zurückgegeben

ist dies die einzige lösung für mein problem?
.htaccess SecFilterEngine Off SecFilterScanPOST Off

weiss jemand ob in nächster zeit ein uploader geplant ist, der problemlos auf allen systemen läuft? danke

Ich habe nun die .htaccess im httpdocs angepasst und es funktioniert!

<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>

Weiss jemand ob dadurch Sicherheitslücken entstehen?

Sollte eigentlich problemlos sein. Sicherheitshalber würde ich das aber noch auf die upload.php beschränken (per zusätzlichem <file>-Block).

Danke für Deine Antwort!

Muss die Anweisung eigentlich auf der obersten Ebene (httpdocs) erfolgen?

Im Ordner /typolight hätte ich sonst bereits eine .htaccess (seit der schweren Sicherheitslücke)

Wäre dies so richtig?

<FilesMatch "(ftp|install)\.php$">
...
...
...
</FilesMatch>

<Files upload.php>
SecFilterEngine Off
SecFilterScanPOST Off
</Files>


Danke und Gruss

Unter /typolight bzw. neuerdings /contao ist es sogar besser. Anweisung sollte so passen.

Ich habe gerade bemerkt, dass man bei quoka.de (Kleinanzeigenportal) beim Erstellen einer Anzeige mehrere Bilder in einem Rutsch hochladen kann, das funktioniert ohne Flash und ist auch ganz nett gemacht, man kann genau sehen welche Datei gerade übertragen wird.
http://www.quoka.de/

Meint ihr das wäre evtl. eine Alternative zu dem Fancy Upload der ja doch viele Probleme bereitet?

Funktioniert! :D

Danke FloB!

Bei mir funktioniert Fancy auch nicht mehr... Will heissen: Es wird zwar irgendwas mit den Dateien gemacht - jedenfalls gemäss Fortschrittbalken - aber nachher erhalte ich auch die roten Ausrufezeichen. Weiter aber keine Hinweise zu Fehlern oder der Ursache...

In der letzten Version 2.8.irgendwas hat alles noch tiptop funktioniert, die "Verweigerung" tritt erst seit dem Update auf 2.9 auf...

Schon die andere Apache-Konfiguration ausprobiert? Kannst du genauer Debuggen, welche Status Codes gesendet werden und wo das Skript abbricht?

Hm, da musst du mir jetzt ein bisschen helfen: Wo bekomm ich die Infos her? Ich kann keine Logs zu Fancy finden und bekomme auch keine Fehlermeldungen im Backend angezeigt (entsprechende Einstellungen im Backend aktiviert)

Was ich auch probiert habe: Die .htaccess mit

SecFilterEngine Off
SecFilterScanPOST Off

ergänzt. Beim Aufruf der Website erhalten ich dann aber vom Server

Zitat:

---

Serverfehler!
Die Anfrage kann nicht beantwortet werden, da im Server ein interner Fehler aufgetreten ist. Der Server ist entweder überlastet oder ein Fehler in einem CGI-Skript ist aufgetreten.
Error 500

---

ok, was ich noch bieten kann, ist folgendes aus dem Webserver-Log:

Zitat:

---

[Mon Jul 26 08:44:18 2010] [alert] [client 83.76.135.48] /home/tcjrch/www/tcjr.ch/.htaccess: Invalid command 'SecFilterEngine', perhaps misspelled or defined by a module not included in the server configuration

---

Das war, als ich die .htaccess ergänzt hatte....

Beim Versuch, eine Datei hochzuladen, schreibt der Webserver folgenden Eintrag:

Zitat:

---

[Tue Jul 27 16:24:39 2010] [error] [client 85.2.67.43] ModSecurity: Multipart error: Multipart: Final boundary missing. [hostname "www.tcjr.ch"] [uri "/contao/upload.php"] [unique_id "TE7sFtkaNhUAAELis4wAAAA2"]

---

Kann jemand damit etwas anfangen?

Ist man zu dem Thema schon weiter und ich hab was verpasst?

Langsam …

Also die HTACCESS-Angaben kannst du streichen, da das Modul gar nicht aktiviert ist bzw. du keinen Zugriff auf die Einstellungen hast.

Zitat:

---

Zitat von tinoo

Beim Versuch, eine Datei hochzuladen, schreibt der Webserver folgenden Eintrag:

Code:

---

[Tue Jul 27 16:24:39 2010] [error] [client 85.2.67.43] ModSecurity: Multipart error: Multipart: Final boundary missing. [hostname "www.tcjr.ch"] [uri "/contao/upload.php"] [unique_id "TE7sFtkaNhUAAELis4wAAAA2"]

---

Kann jemand damit etwas anfangen?

---

Hm, das ist Tricky. ModSecurity scheint wohl doch das Problem zu sein. Mal nach der Fehlermeldung gegooglet? Was sagt Contao-Check?

easy, ich will ja nur zur Lösung des Problems beitrageb... :D

Gegooglet hab ich, aber schlau werd ich nicht. Das übersteigt mein technischen Verständnis.

Contao-Check meldete bei einzelnen Datei CHMOD-"Fehler", allerdings nur bei vereinzelten Bildern und/oder Language-Dateien. Ansonsten ist alles grün...

Eine Fancy-Alternative:

http://jupload.sourceforge.net/applet-basic.html

???

Ein Java-Applet ist wohl keinen gute Alternative zu Flash. Gesucht ist ja eine Variante, die ohne Plugins auskommt.

hm, in einem anderen CMS (phpwcms) haben sie mit UploadFX das gleiche Problem. Einer schreibt da:

Zitat:

---

Verantwortlich für die Schlappe von UploadFX sind zwei Sachen: Erstmal, dass die FileReference Klasse des Adobe Flash Players offensichtlich einen Bug hat und zweitens, dass mod_security (Eine Serverfirewall) diesen Bug nicht tolleriert.

---

Das Multiple File Upload offensichtlich nur mit Flash oder Java geht, werden wir uns wohl das kleiner Übel aussuchen müssen... :(

Wie Russe schon schrieb, gibt es schon reine JavaScript-Lösungen (bspw. auf www.quoka.de). Hab ich gerade selber mal ausprobiert und dort wird wirklich kein Flash oder Java verwendet. Es geht also schon.

HTML5 kann das, allerdings nicht asynchron (wie FancyUpload u. a.). Somit greift das max_file_size früher als zur Zeit (grade bei Bilduploads problematisch).

Wie finde ich bei der genannten Seite den JS-Only-Upload?

Kostenlos Inserieren (roter Pfeil) --> Tiermarkt --> Hunde --> runterscrollen bis "Bilder hinzufügen"

Wäre eine tolle Lösung...

... wobei die Javascript-Lösungen offensichtlich das "Problem" haben, dass zwar mehrere Dateien hochgeladen werden können - aber auswählen kann man immer nur eine Datei (keine Mehrfachauswahl im Browserfenster möglich!!!) Bei 35 Fotos heisst das 35mal klicken... :eek:

So wie hier: http://the-stickman.com/files/mootools/multiupload/

Jep, das ist natürlich das Manko der JavaScript-Lösungen. Dann kommt man wohl doch nicht an Flash vorbei.

Zitat:

---

Zitat von tinoo

aber auswählen kann man immer nur eine Datei (keine Mehrfachauswahl im Browserfenster möglich!!!) Bei 35 Fotos heisst das 35mal klicken...

---

Das hast du auch, wenn du FancyUpload deaktivierst.

... Ich will Fancy aber nicht deaktivieren! Ich will, dass es wieder läuft!

Ich sag ja nur, dass eine Alternative, bei welcher du nicht sofort mehrere Dateien zum Upload markieren kannst, keine Alternative ist, da wir das bereits haben.

genau! wenn du das so schreibst, versteh ich's auch ;)

Find mal bitte heraus, welche Apache httpd und mod_security Versionen eingesetzt werden.

Zum Thema:

• http://www.modsecurity.org/documenta...es.html#N1101E
• https://www.modsecurity.org/tracker/browse/MODSEC-19
• https://www.modsecurity.org/tracker/browse/CORERULES-21
• https://www.modsecurity.org/tracker/browse/MODSEC-21
  

Mit der File API (HTML5/DOM3) könnte man FancyUpload großteils ersetzen. Mangelt halt an Cross Browser Support.

https://developer.mozilla.org/en/usi...b_applications

Ich habe folgendes Problem mit Fancy Upload:

Kleine Dateien kann ich Problemlos hochladen, aber bei großen (zb.: 40mb) erscheint nach dem Upload kurz die Meldung: File partlly uploaded, und dann kommt die Fehlermeldung bitte Datei auswählen neben dem Formularelement.

Ich habe mit dem EFG ein Formular erstellt und als Typ FancyUpload ausgewählt. Datenlänge steht auf 0, aber auch andere Werte bringen kein positives Ergebnis. Ich hab dann mal die fancylog erstellt und da ist folgender Eintrag:

Code:

---

[FORM_DATA] => Array
        (
            [FORM_SUBMIT] => auto_form_8
            [MAX_FILE_SIZE] => 2048000
            [FORM_PAGE] => 1
            [Videotitel] => Testvideo
            [email] => blabla@yahoo.de
            [Beschreibung] => Dies ist ein Testvideo
        )

    [FILES] => Array
        (
        )

    [EFP] => Array
        (
            [FORMDATA] => Array
                (
                    [Videotitel] => Testvideo
                    [email] => blabla@yahoo.de
                    [Beschreibung] => Dies ist zum Testen des Uploadscripts
                    [Datei_auswählen] =>
                    [48] =>
                    [_formId_] => 8
                )

        )

---

Woher kommt der Max_File_Size Wert? In den Systemeinstellungen habe ich auch schon den Wert erhöht.

DAnke für die Antworten

MAX_FILE_SIZE wird von PHP vorgegeben. Wenn du MAX_FILE_SIZE in der php.ini änderst, musst du noch darauf achten, dass MAX_POST_SIZE entsprechend angepasst wird.

Dateien mit 40MB Größe sollten (wenn der Server keine speziellen Aufgaben hat) per FTP o. ä. hochgeladen werden, da du davon ausgehen kannst, dass bei solchen Größen dir (in vielen Konfigurationen) der Apache und PHP zusammenklappt.

Zitat:

---

Zitat von FloB

Find mal bitte heraus, welche Apache httpd und mod_security Versionen eingesetzt werden.

---

Apache 2.2.13
über mod_security schweigt sich der Hoster aus...

Zitat:

---

Zitat von tinoo

über mod_security schweigt sich der Hoster aus...

---

Is doof. Infos werden gebraucht.

naja... alle Indizien sprechen dafür, dass Flash irgendwas falsch macht... Auszug aus
http://digitarald.de/project/fancyupload/

Zitat:

---

Uploads fail with 406/403 error
From the swfupload documentation (it applies to all Flash scripts depending on FileReference):
If you are using Apache with mod_security this will not work, you need to put the following in your .htaccess file to disable mod_security:
SecFilterEngine Off SecFilterScanPOST Off
Disabling mod_security isn’t allowed on some shared hosts, and only do this if you know what you are doing. This is due to a bug in the way that flash sends the headers back to the server according to the Flash 8 documentation

---

Du wirst aber Flash nicht ändern können.

Zitat:

---

Zitat von FloB

Mit der File API (HTML5/DOM3) könnte man FancyUpload großteils ersetzen. Mangelt halt an Cross Browser Support.

https://developer.mozilla.org/en/usi...b_applications

---

Scheint aber die Zukunft zu sein, denke ich. Und die anderen Browser werden dem ja schon nachkommen.
Vielleicht kann man das ja auch prüfen ob das der Browser kann, und falls nicht eine Alternative (Flash oder bisherige Auswahl) ausgeben?

Zitat:

---

Zitat von Russe

Scheint aber die Zukunft zu sein, denke ich. Und die anderen Browser werden dem ja schon nachkommen.

---

Ja, und Firefox ist ja auch kein Exote...

Kann sich ja mal ein JSler ransetzen. Möglicherweise kann man sich von jQuery plupload was abschauen.

Anzumerken ist, dass auch der Firefox noch nicht alle Möglichkeiten bietet (Dateien können noch nicht als BLOB behandelt werden, was bei allen Nicht-Text-Dateien sehr sinnvoll bzw. nötig wäre, zudem könnte man sogar große Dateien in kleinere aufteilen bzw. Dateien in mehreren Teilen parallel hochladen), für eine Basisimplementation reicht es jedoch schon (und Firefox 4 ist ja nicht mehr weit).

Sind die Probleme mit FancyUpload dem Contao-Team überhaupt bekannt? Wenns an Flash liegt, müssten ja dutzende andere User auch betroffen sein... Wird an einem Ersatz gearbeitet oder gesucht? Oder muss man da zuerst ein Ticket eröffnen? Man bekommt so gar nicht mehr mit, was die Jungs und Mädels grad am machen sind... :(

Ja, das Thema ist Leo bekannt und er hatte ja auch den FancyUpload so geändert, dass er mit dem fehlerhaften Flash-pLugin funktioniert. Die immer noch vorhandenen Probleme bei einigen Nutzern kommen vermutlich eher von Servererweiterungen wie mod_security und Co. und bestimmten Einstellungen darin. Dagegen kann Leo nicht viel unternehmen.

Gruß

Die Probleme tauchen (bisher) nur in Verbindung mit aktiviertem mod_security auf und sind in Flash begründet. Wenn man mod_security nicht gezielt abstellt, gibt es leider keinen Fix für dieses Problem, bis Adobe reagiert.

Die Probleme vor der aktuellen Implementierung waren nur bedingt auf Flash zurückzuführen, die durch eine elegante Lösung umgangen werden konnten.

BTW: Hast du Flash 10.1 installiert?

Zitat:

---

Zitat von FloB

BTW: Hast du Flash 10.1 installiert?

---

Wenn man der Systemsteuerung glaubt, ist "Adobe Flash Player 10 Plugin" in der Version 10.1.53.64 installiert... Wenn man der Adobe-Seite glaubt, wird bestätigt, dass ich Version 10.1.82.76 installiert habe... :(

Ich mach mal ein Update von Hand und berichte wieder...

[edit]

Hm, kein Update möglich, da bereits die neuste Version installiert ist... :rolleyes: