Mit TL 2.8: Fehler beim Datei-Upload

[Sebastian]

HI

Beim Hochladen von Dateien in ein frisch installiertes TYPOlight-System (2.8 RC2) gibt das Javascript immer einen Fehler aus, und die Dateien werden nicht hochgeladen. Das sieht dann so aus:



Die Verzeichnisrechte stimmen. Ich kann absolut keine Dateien hochladen, Verzeichnisse anlegen geht aber.

Das System: Mac OS 10.6.2 mit Apache 2.2.11 und PHP 5.2 sowie MySQL 5.

Weiß jemand, was das Problem sein könnte?

Sebastian

[Sebastian]

HI

ich habe nun das gleiche Problem auch noch auf einem Fedora-Server. Kann das jemand auch bei sich reproduzieren? In der Online-Demo geht es wegen der deaktivierten Uploads sowieso nicht.

Sebastian

[leo]

FancyUpload funktioniert in geschützten Verzeichnissen nur mit einem Workaround.

[Sebastian]

HI Leo

danke für die Antwort. Bei der lokalen Testinstallation war es tatsächlich ein geschütztes Verzeichnis, ich werde dort den Workaround testen. Bei der Seite auf dem Fedora-Server handelt es sich allerdings um ein öffentlich zugängliches Verzeichnis. Der Upload tut trotzdem nicht. Mal sehen ob es dort auch mit dem Workaround erledigt wird. Ansonsten liegt der Fehler wohl woanders

Edit: Hmm, der Ticket-Ersteller sagt, Firefox stürze dabei ab. Das ist bei mir nicht der Fall. Ich teste aber den Workaround trotzdem. Außerdem ist es dort eine Passwortabfrage, hier nur der TYPOlight-Schutz.

Sebastian

[Sebastian]

HI

der Workaround tut bei mir nichts. Andreas (als Ticketersteller) hat wohl einen Passwortschutz über mod_auth laufen, während ich nur ein Verzeichnis über das Schloss in der Dateiverwaltung geschützt habe (Disallow All, oder so ähnlich). Und das nur bei einer Installation, die andere ist nicht geschützt.

Trotzdem tritt der Fehler auf, bei zwei Installationen auf komplett unterschiedlichen Systemen (bei beiden braucht man keinen SMH), bei unterschiedlichen Dateien und Dateitypen, unabhängig von den Benutzerrechten. Funktioniert denn bei irgendjemandem der Dateiupload korrekt?

SelfHTML erklärt mir, der Fehler 400 sei das:

Die Anfrage enthält Syntaxfehler. Der Server kann die Anfrage deshalb nicht bearbeiten. Das kann beispielsweise vorkommen, wenn der verwendete Browser einen Programmierfehler aufweist und ungültige Anfragen sendet, oder ein Mensch versucht, händisch (also etwa mit telnet) mit dem Server zu kommunizieren und dabei einen Fehler macht.

Kann es an einem Fehler des Fancy-Upload-Scripts liegen?

Sebastian

[Sebastian]

HI

es kommt mir immer mehr seltsam vor, dass das nur bei mir auftreten soll, und dann auch noch in ganz unterschiedlichen Umgebungen. Kann sich bitte mal jemand melden, bei dem das nicht auftritt?

Könnte es daran liegen, dass in der Ordnerstruktur ein geschützter Ordner existiert, obwohl nicht in diesen hochgeladen wird? Dass sich also FancyUpload von der irrelevanten Umgebung beeinflussen lässt?

Sebastian

[FloB]

Habe das Problem hier auch. Fehler 400, keine weiteren Angaben in den Logs. Eintrag aus der access.log:

62.214.193.122 - - [16/Jan/2010:02:00:11 +0100] "POST /typolight/upload.php?do=files&act=move&mode=2&pid=tl_files/elements&id= HTTP/1.1" 400 1428 "-" "Adobe Flash Player 10"

Das einzig interessante ist hier, dass kein Referer gesendet wurde.

System: Debian Lenny (5), Apache 2, mod_suphp (alles aktuell). Gibt keinen besonderen Schutz der Verzeichnisse. .htaccess.default wird verwendet. Sonstige Konfiguration:

<Directory />
        AllowOverride None
        Order Deny,Allow
        Deny from all
</Directory>
<Directory /home/defaultwww>
        Order Deny,Allow
        Allow from all
</Directory>
<Directory /home/*/www>
        Order Deny,Allow
        Allow from all
</Directory>
<Location /typolight/install.php>
        AuthType Digest
        AuthName "Configuration"
        AuthDigestDomain /typolight/
        AuthUserFile /home/defaultwww/.htdigest
        Require valid-user
</Location>
# in der config des virtual host:
        <Directory /home/user/www>
                Options SymLinksIfOwnerMatch
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>

Ich muss jetzt JavaScript deaktivieren, damit ich Dateien übers Backend hochladen kann. Vielleicht wäre es nicht schlecht eine Option einzubauen, um FancyUpload zu deaktiveren!?


Edit: Konsole meldet auch keine Fehler, nur einen CSS-Fehler:

#fancy-list li.file .file-info{display:block;margin-left:44px;font-size:.9em;line-height:20px;clear;}

Die letzte Eigenschaft (clear) hat gar keinen Wert – sollte man noch korrigieren .


Edit 2: Achja, ich setze den aktuellen Nightly Build ein (R103).

[Sebastian]

HI

es freut mich natürlich, dass jemand anders auch dieses Problem hat (mein Beileid)…

Soll ich ein Ticket erstellen und den Bug melden, oder nur ein Feature-Request für die deaktivieren-Option erstellen?

Sebastian

[FloB]

Beides? It's up to you.

Ich denke Priorität hat erstmal eine Deaktivieren-Option (vllt auch auf eine per-User-Basis?), wenn es sich um einen Bug handelt, kann man das immernoch in einem Maintenance-Release beheben.

[Sebastian]

HI

Feature #1423.

Sebastian

[FloB]

Leo hat es als Duplicate abgelehnt (was ja so nicht stimmt). Du hast vielleicht nicht deutlich genug hervorgehoben, dass du eine Funktion zum Abschalten von FancyUpload wünschst … Der Titel sagt das auch nicht grade aus .

[Sebastian]

HI

ich habe jetzt nochmal nachgehakt. Den Titel kann ich aber nicht ändern. Du kannst mich ja unterstützen

Sebastian

[FloB]

Hab mal eine ForensicLog geschrieben, Beispiel (Host ersetzt, der ist korrekt):

+1441:4b51decc:7|POST /typolight/upload.php?do=files&act=move&mode=2&pid=tl_files/galleries/body&id= HTTP/1.1|Host:www.domain.tld|Connection:close|User-Agent:Adobe Flash Player 10|X-Flash-Version:10,0,32,18|Accept-Types:text/*|Content-Type:multipart/form-data; boundary=----------ae0gL6Ij5cH2ae0GI3ei4ei4ae0ei4|Content-Length:141527
-1441:4b51decc:7

Also aufgebrochen:

POST /typolight/upload.php?do=files&act=move&mode=2&pid=tl_files/galleries/body&id= HTTP/1.1
Host:www.domain.tld
Connection:close
User-Agent:Adobe Flash Player 10
X-Flash-Version:10,0,32,18
Accept-Types:text/*
Content-Type:multipart/form-data; boundary=----------ae0gL6Ij5cH2ae0GI3ei4ei4ae0ei4
Content-Length:141527

Da fällt mir nichts auf, was sonderlich "malformed" sein soll. Leider schweigt sich Apache drüber aus, was er nicht mag. Bzw. ich habe noch keine Methode gefunden, diese Infos zu besorgen.

[Sebastian]

HI

Leo meint, wir sollen mal die Herstellerseite von Fancy-Upload durchwühlen. Ich kann das dieses Wochenende nicht machen, willst du dich solange damit vergnügen? Ansonsten mache ich das nächste Woche.

Sebastian

[FloB]

Ich versuche mal herauszufinden, welchen Header mein Server nicht mag (yeah, telnet und try & error -.-). Wenn wir das haben, können wir zu Digitarald gehen …

Edit: Die Herstellerseite hatte ich als erstes gecheckt und nichts auf Anhieb gefunden, was uns weiterhelfen könnte. Ging dort nur um ein Zugriffsrechteproblem.

[FloB]

Ok, jetzt bin ich offiziell verwirrt.

GET /typolight/upload.php HTTP/1.1
Host:www.domain.tld

HTTP/1.1 400 Bad Request
Date: Sat, 16 Jan 2010 16:18:00 GMT
Server: Apache/2.2.9
Vary: Accept-Encoding
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html

f
Illegal request
0


GET /typolight/ HTTP/1.1
Host:www.domain.tld

HTTP/1.1 200 OK
Date: Sat, 16 Jan 2010 16:16:25 GMT
Server: Apache/2.2.9
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=…; path=/
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

ee9
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
…

Irgendjemand ne Ahnung, was da passiert?

Edit: OK, das wird wohl von der upload.php direkt ausgegeben …

[Sebastian]

HI

ganz generell: Wenn es ein Fehler im Fancy-Upload ist, liegt der dann in der Flash-Datei, oder hier?

Sebastian

[FloB]

Kann ich dir nicht sagen … Wäre aber ne Idee, im JS-Script mal einen Debugger zu installieren, um zu schauen, was für ein Inhalt zurückgegeben wird. Allerdings kann ich das nicht direkt machen, bin nicht so der große JS-ler. Ich konzentriere mich grade auf die anderen Teile (HTTP-Request, PHP-Code).

Ich kann schonmal ausschließen, dass die upload.php direkt daran Schuld ist. Volltextsuche findet nur ein weiteres Vorkommen des 400er-Codes in der initialize.php …

[FloB]

OK, ich hab das Problem:
In der initialize.php wird der Referer bei Uploads überprüft. Ausnahme ist, wenn $_POST['FANCY_KEY'] mit einem in der Session gespeichertem Wert übereinstimmt. Leider ist das Session-Array bei mir leer.

Sebastian (und jeder andere, der will), du kannst mal in die initialize.php, Zeile 161 folgendes einbauen (mit ein paar Zeilen vorne- und hintendran):

if ($_POST && !$GLOBALS['TL_CONFIG']['disableRefererCheck'] && !(strlen($objInput->post('FANCY_KEY')) && $objInput->post('FANCY_KEY') == $_SESSION['FANCY_KEY']))
{
        $self = parse_url($objEnvironment->url);
        $referer = parse_url($objEnvironment->httpReferer);
        log_message('Fancy: '.print_r($objInput->post('FANCY_KEY'),true).' SESSION:'.print_r($_SESSION,true), 'fancy.log'); // neu: Zeile 161

        if (!strlen($referer['host']) || $referer['host'] != $self['host'])
        { 

Dann bitte versuchen etwas hochzuladen und danach die "/system/logs/fancy.log" kontrollieren.

Scheint, als würde bei uns zumindest beim FancyUpload die Session nicht wieder aufgenommen (Cookies somit nicht übertragen) werden. Da müsste Leo jetzt ran und herausfinden, warum die Session nicht mit den richtigen Daten initialisiert wird oder einen alternativen Übertragungs- und Auswertungsweg für die Session-ID finden bzw. einen anderen Weg finden den Uploadrequest zu validieren.

Mein lokales System: Mac OS X 10.5.8, Firefox 3.5.7, Adobe Flash 10,0,32,18.

IMO sollte die Option FancyUpload per User deaktivieren zu können dringend hinzugefügt werden. Wer weiß, was da noch für Konfigurationen 'rumlaufen, die mit dem System nicht zurecht kommen.

Edit: Auch Safari 4.0.4 will nicht.

[FloB]

Ich habe mal ein bisschen rumgespielt. Wie ich es auch anstelle, das Session-Array bleibt komplett leer. Die Session scheint auch korrekt hergestellt zu werden bzw. die Session-IDs stimmen überein. Trotzdem bleibt das Session-Array leer. Da kann natürlich niemals die Tokenprüfung stattfinden.

Jetzt würde ich gerne noch andere hören, bei denen FancyUpload funktioniert: Ist euer Session-Array korrekt? Welche Revision benutzt ihr?


Edit: Auch wenn ich den Check auf korrekten Token deaktiviere (Zeile 158), funktioniert der Upload bei mir nicht. Wird kein Fehler angezeigt, nur das Warndreieck erscheint … alter Upload funktioniert nach wie vor.

 if ($_POST && !$GLOBALS['TL_CONFIG']['disableRefererCheck'] && !(strlen($objInput->post('FANCY_KEY')) /*&& $objInput->post('FANCY_KEY') == $_SESSION['FANCY_KEY']*/))

[Andreas]

Hallo FloB,

bei mir hatte es ja erst auch nicht funktioniert mit RC1 und dann mit RC2 ging es auf einmal. Link zum Thread unten [1].

Windows XP, FF3.5.7

Ich hab mir die Session-Variablen jetzt mal ausgeben lassen mit

<?php
  echo '<pre>';
  print_r($_SESSION);
  echo '</pre>';
?>

Das Array ist reichlich gefüllt, kannst du mir bitte genau sagen, welche Variable ich mir ausgeben lassen soll?

Mit obigem PHP-Code kann ich fancyupload aber leider nicht starten, dann kommt die Meldung:

A required file was not found, please be patient and we fix this.

@Nina
Kannst du die beiden Threads vielleicht zusammen legen. Meiner hätte eigentlich fortgeführt werden müssen, da es genau die gleiche Thematik ist.

[1]2.8.RC1 Dateiverwaltung, Upload mit Firefox geht nicht [2.8.RC2 jetzt ok]

Wenn ihr meint kann ich den Titel auch wieder ändern.

Gruß Andreas

[FloB]

Wo hast du die Testausgabe eingefügt?

Die Ausgabe der Sessiondaten sollte dort erfolgen, wo FancyUpload kleben bleibt. Das ist bei mir in der /system/initialize.php, Zeile 158. Damit du Testausgaben sehen kannst, sehe ich nur die Möglichkeit diese in eine Logfile zu schreiben. Dazu habe ich in der initialize.php in Zeile 161 folgendes eingefügt:

        log_message('Fancy: '.print_r($objInput->post('FANCY_KEY'),true).' SESSION:'.print_r($_SESSION,true), 'fancy.log'); 

Sollte bei dir die /system/logs/fancy.log nicht geschrieben werden, kannst du diese Codezeile auch mal unterhalb der if-Schleife schreiben (Achtung, das Log wird sicher sehr schnell sehr groß – kannst noch eine if-Schleife einbauen, die überprüft, ob FANCY_KEY übertragen wird, bevor die Logfile geschrieben wird).

Vielen Dank schonmal für deine Hilfe!


Wie ich sehe hat Leo jetzt das Ticket angenommen, damit haben wir zumindest eine Lösung. Trotzdem hätte ich FancyUpload bei mir gerne am laufen .

[Sebastian]

HI

ich werde das auch noch prüfen (wenn ich Zeit habe ), aber ich glaube, das Ergebnis wird das gleiche sein. Wir brauchen jemanden, bei dem es wirklich tut.

Sebastian

[Andreas]

Sorry für spät!

Hab die Zeile jetzt dort eingefügt und mir die Ausgabe angeschaut. Die Variablen sind leer.

@Sebastian
Bei mir funktioniert es mit RC2 ja einwandfrei, hab ich doch schon oft geschrieben. ABER: Nachdem ich jetzt die Zeile eingefügt hatte, geht's nicht mehr. ??? Ist wie vorher, mit dem obigen Screenshot. Hab mal Browser-Cache und Sitzungscookies gelöscht, kein Erfolg. Echt Mist.

Andreas

[Andreas]

FloB,

im IE funktioniert es ja und dort ist der Log auch leer:

[18-Jan-2010 19:32:31] Fancy:  SESSION:Array
(
    [BE_DATA] => 
    [FE_DATA] => 
)

[18-Jan-2010 19:34:18] Fancy:  SESSION:Array
(
    [BE_DATA] => 
    [FE_DATA] => 
)

Ist das nicht der falsche Platz in der initialize.php? Denn das Log wird dann bei mir nur geschrieben, wenn ich mich im BE anmelde. Ich hatte meine Zeilen vorher im BE-Template be_main.tpl.

[Andreas]

Ich hab die Zeile jetzt mal in die main.php eingefügt. Die Variable $objInput->post('FANCY_KEY') bleibt sowohl im FF, als auch im IE leer.

[FloB]

Die Variable wird nur übertragen, wenn du eine Datei hochlädst, das sollte klar sein.
Bei mir ist es so, dass TL beim Upload in der initalize.php aussteigt, und zwar auf Grund der fehlenden Session-Variable, die in Zeile 158 abgefragt wird. Da ist einfach nichts drin. Ich kann mir auch nicht erklären, warum die leer ist – wo sind da die ganzen Daten hin? PHP scheint die Session nicht wieder zu starten. Wenn ich mir das Session-Array sonst anschaue (also alle Requests außer FancyUpload) ist alles i. O.
Ich versteh das nicht … iwie scheint sich das Flash nicht mit PHP zu verstehen …

[FloB]

Ich hab die Zeile jetzt mal in die main.php eingefügt. Die Variable $objInput->post('FANCY_KEY') bleibt sowohl im FF, als auch im IE leer.

Bei mir wird sie korrekt befüllt. Funktioniert der Upload bei dir eigentlich jetzt oder nicht?

[Andreas]

Nein, wie gesagt: Hatte bis gestern funktioniert und jetzt nicht mehr. Geht nur noch im IE. Im FF hab ich obigen Screenshot als Fehler.

Ich hab jetzt das in der main.php am Ende:

log_message('Fancy: '.print_r($objInput->post('FANCY_KEY'),true).'
 SESSION:'.print_r($_SESSION['FANCY_KEY'],true), 'fancy.log'); 

Sowohl im FF als auch im IE hab ich sowas im Log:

[18-Jan-2010 20:43:43] Fancy:  SESSION:
[18-Jan-2010 20:44:57] Fancy:  SESSION:e3ec10b3a2f457df7423a324e2cd5125

Also $objInput->post('FANCY_KEY') bleibt immer leer.

[FloB]

Es ist halt komisch, dass es im IE funktioniert: Eigentlich läuft ja Flash unabhängig. An spezifischen Erweiterungen im FF kann es ja auch nicht unbedingt liegen, da der Safari den selben Fehler hat. Trotzdem sollten wir das mal durchgehen … was hast du für Erweiterungen im FF installiert?

Meine Erweiterungen:

Anwendung: Firefox 3.5.7 (20091221151141)
Betriebssystem: Darwin (x86-gcc3)

- Abduction! 3.0.4
- Adblock Plus 1.1.3
- ChatZilla 0.9.86
- ColorZilla 2.0.2
- CookieCuller 1.4
- DOM Inspector 2.0.4
- Double-Click to Reload Tabs 1.1.1.1
- DownloadHelper 4.7
- Extension List Dumper 1.14.4
- Feed Sidebar 4.1.2
- Firebug 1.4.5
- Live HTTP headers 0.15
- Menu Editor 1.2.6
- Minimap Addon 0.3.13
- NoScript 1.9.9.35
- OptimizeGoogle 0.77
- Organize Status Bar 0.6.4
- Read It Later 2.0.3
- Smart Middle Click 0.5.1.2.1
- Stop-or-Reload Button 0.2.2.1
- SubmitToTab 0.3.5
- URL Fixer 1.6
- Web Developer 1.1.8
- WebMynd 0.9.1.1
(deaktiviert)
- WOT 20091028
(deaktiviert)
- YSlow 2.0.2
- Zotero 1.0.10

Ich kann die jetzt nicht alle durchgehen und schauen, welches verantwortlich ist – ich versuch das nächstes WoE zu machen.

[Andreas]

Ich glaub nicht dass es daran liegt. Schau mal in meinem anderen Thread dazu. Dort habe ich aufgelistet, in welchen Browsern ich getestet hatte und FF immer auch im safe mode, also ohne addons.

[FloB]

Hast du FF auch jetzt mal im SafeMode getestet?

Hm, könnte es vielleicht mit einem Firefox-Update zusammenhängen?

[Andreas]

Hab jetzt nochmal getestet, 2x im safe mode. FF 3.5.7 portable und FF 3.5.6. Geht in beiden nicht.

Hast du die Liste meiner getesteten Browser gesehen? Geht mit Fiirefox 3.0.15. Kann ich aber jetzt nicht mehr testen.

Andreas

[FloB]

Es scheint auf meiner XP-SP3-VM mit FF 3.0.17 zu gehen, es wird zumindest nicht mehr der "Bad Request" angezeigt (ich habe wohl noch ein zweites Problem mit dem Upload).

Ich muss mir das nochmal genauer anschauen, aber heute wohl nicht mehr.

[Andreas]

Aus unbekannten Gründen funktioniert es jetzt wieder in FF 3.5.7 und RC2

[Sebastian]

HI

bei mir nicht Hast du da die neuste Revision im Einsatz?

Sebastian

[Andreas]

Wie gesagt, TL 2.8.RC2 FF 3.5.7. Hab eigentlich nix geändert.

[FloB]

Irgendwelche Updates? Firefox, Flash, Server-Software etc.?

[Sarvo]

also bei mir funktioniert es ebenfalls, hatte diese Probleme auch überhaupt noch nicht.
Ich werde die Tage das mal mit dem loggen ausprobieren und sag euch bescheid ob mein Array gefüllt ist

System Win7 , FF3.6, unter FF 3.5 hats auch funktioniert sowohl mit RC1 und RC2

[FloB]

So, Revision 141 drauf, Problem bleibt weiterhin bestehen. Immerhin kann ich FancyUpload jetzt deaktivieren.

Ich habe auch mal testweise die Referer-Prüfung abgestellt, damit wird auch die Überprüfung auf FANCY_KEY umgangen. Dann kommt zwar kein #400-Fehler mehr, aber Upload funktioniert trotzdem nicht (Achtung-Zeichen ohne weitere Infos). Strange.

Nunja, wir haben ja jetzt erstmal Zeit das erste Problem zu lösen. Irgendjemand eine Idee?