Upload funktioniert nicht

Hallo,

ich bin gerade auf ein kleines Problem gestoßen. Die Situation ist wie folgt:

Ich habe auf einem Server im lokalen Netzwerk den Shop (v6.3) aufgesetzt und eine initiale Konfiguration vorgenommen. Wenig später bin ich mit dem Shop auf einen externen Server im Web umgezogen. Es handelt sich dabei um einen shared-Server. Danach Update auf v6.4.1 + SSL + Module von eComstyle - alles läuft soweit ganz gut.
Als ich nun Produktbilder hochladen wollte, ist mir aufgefallen, dass diese nicht gespeichert werden, und auch bei Klick auf Vorschau nicht angezeigt werden (weisse Seite).
In dem Verzeichniss wird nichts gespeichert, obwohl die Rechte auf 777 gesetzt sind, und der Webbenutzer als Besitzer eingetragen ist.
Unter dem Punkt Systemgesundheit ist alles auf grün.
Woran kann es noch liegen? - Was übersehe ich hier?

Moin :slight_smile:

dies wird sicherlich mit den Namespaces und Referenzierung der Klassen die im vendor Verzeichnis generiert wurden sind zusammen hängen.

Dies wird wahrscheinlich der Knackpunkt sein, wenn Du das vendor Verzeichnis einfach nur hochlädst wird es noch die Verzeichnisstruktur vom lokalen Netzwerk haben.

Am Besten aktualisierst Dir Dein vendor Verzeichnis. Dies kannst tun, indem sicherheitshalber Dein aktuelles vendor Verzeichnis mit Unterstrich versiehst und über den Composer Befehl

composer install --no-dev

Dir das vendor Verzeichnis neu bauen lässt inkl. Namespaces und Referenzierung der Klassen.

Viele Grüße,
Tim

Vielen Dank für die Antwort. Das ahbe ich natürlich schon getan, als ich die Module teilweise neu installieren musste. Auch ein erneuter Aufbau des vendor-Verzeichnisses hat keine Wirkung gezeigt.
Auch im Error-log ist keine Info eingetragen. Im Access-Log finde ich folgende zeile beim Datei-upload:

172.70.250.80 - - [01/Mar/2022:12:01:02 +0100] "POST /stage1/source/admin/index.php?editlanguage=0&force_admin_sid=014604722975a45f5e011524f897e7b9&stoken=277A28B& HTTP/1.1" 200 10990 "https://meinedomain.tld/stage1/source/a$
172.70.250.80 - - [01/Mar/2022:12:01:13 +0100] "POST /stage1/source/admin/index.php?editlanguage=0&force_admin_sid=014604722975a45f5e011524f897e7b9&stoken=277A28B& HTTP/1.1" 200 11106 "https://meinedomain.tld/stage1/source/a$
172.70.251.21 - - [01/Mar/2022:12:01:14 +0100] "GET /stage1/source/out/pictures/generated/product/1/390_245_75/6_b-100-pl-san.jpg HTTP/1.1" 404 5875 "https://meinedomain.tld/stage1/source/admin/index.php?editlanguage=0&force$
172.70.250.24 - - [01/Mar/2022:12:01:14 +0100] "GET /stage1/source/out/pictures/generated/product/1/87_87_75/6_b-100-pl-san.jpg HTTP/1.1" 404 5875 "https://meinedomain.tld/stage1/source/admin/index.php?editlanguage=0&force_a$

Gerne.

Wird das Produktbild den im master Verzeichnis gespeichert? Oder wie macht sich bemerkbar, dass das Produktbild nicht hochgeladen wird?

Dann hilft nur noch Debugging an der Stelle wo die Datei verarbeitet wird.

Es könnte noch daran liegen dass upload_tmp_dir außerhalb von open_basedir liegt.

1 Like

Danke für denTip mit dem master-Verzeichnis. Da hatte ich nicht nachgesehen. Also das Produktbild wird in out/pictures/master/product/1 hochgeladen. Die Rechte sind jedoch auf 644 gesetzt, obwohl der gesamte Verzeichnisstamm auff 775 gesetzt ist.
Über die Vorschau wird jedoch versucht das Bild in dem Ordner out/pictures/generated/product/1/540_340_75/ aufzurufen. Dort wird aber nichts gefunden.

Das open_basedir ist /var/customers/webs/user:/var/customers/tmp/user
und das upload_tmp_dir ist /var/customers/tmp/user

Das ist doch schon mal gut. Also der Titel “Upload funktioniert nicht” konnte somit widerlegt werden.

Das Problem ist, dass die Bilder nicht generiert werden können. Ggfs. fehlen dem generated Verzeichnis die Rechte oder eine PHP Funktion die Bilder generiert ist nicht erlaubt auf Server dort könntest die php.ini Einstellungen prüfen.

Bei der Konfiguration habe ich mich eng an die Vorgaben gehalten.

Die geforderten Module und einige weitere habe ich installiert, und auch aktiviert, da der Composer sonst seine Arbeit nicht getan hätte. Die Konfiguration entspricht der auf dem lokalen Server. GD und imagick sind auch mit dabei:

/opt/php-7.4/etc/conf.d/bcmath.ini, /opt/php-7.4/etc/conf.d/bz2.ini, /opt/php-7.4/etc/conf.d/calendar.ini, /opt/php-7.4/etc/conf.d/ctype.ini, /opt/php-7.4/etc/conf.d/curl.ini, /opt/php-7.4/etc/conf.d/dom.ini, /opt/php-7.4/etc/conf.d/exif.ini, /opt/php-7.4/etc/conf.d/fileinfo.ini, /opt/php-7.4/etc/conf.d/ftp.ini, /opt/php-7.4/etc/conf.d/gd.ini, /opt/php-7.4/etc/conf.d/gettext.ini, /opt/php-7.4/etc/conf.d/gmp.ini, /opt/php-7.4/etc/conf.d/iconv.ini, /opt/php-7.4/etc/conf.d/imagick.ini, /opt/php-7.4/etc/conf.d/imap.ini, /opt/php-7.4/etc/conf.d/intl.ini, /opt/php-7.4/etc/conf.d/json.ini, /opt/php-7.4/etc/conf.d/mysql.ini, /opt/php-7.4/etc/conf.d/mysqli.ini, /opt/php-7.4/etc/conf.d/opcache.ini, /opt/php-7.4/etc/conf.d/pdo.ini, /opt/php-7.4/etc/conf.d/pdo_mysql.ini, /opt/php-7.4/etc/conf.d/pdo_sqlite.ini, /opt/php-7.4/etc/conf.d/phar.ini, /opt/php-7.4/etc/conf.d/posix.ini, /opt/php-7.4/etc/conf.d/readline.ini, /opt/php-7.4/etc/conf.d/session.ini, /opt/php-7.4/etc/conf.d/shmop.ini, /opt/php-7.4/etc/conf.d/simplexml.ini, /opt/php-7.4/etc/conf.d/soap.ini, /opt/php-7.4/etc/conf.d/sockets.ini, /opt/php-7.4/etc/conf.d/sodium.ini, /opt/php-7.4/etc/conf.d/sqlite3.ini, /opt/php-7.4/etc/conf.d/sysvmsg.ini, /opt/php-7.4/etc/conf.d/sysvsem.ini, /opt/php-7.4/etc/conf.d/sysvshm.ini, /opt/php-7.4/etc/conf.d/tokenizer.ini, /opt/php-7.4/etc/conf.d/xmlreader.ini, /opt/php-7.4/etc/conf.d/xmlwriter.ini, /opt/php-7.4/etc/conf.d/xsl.ini, /opt/php-7.4/etc/conf.d/zip.ini

Wird noch etwas benötigt um die Bilder zu generieren?

Verzeichnisrechte habe ich mit 777 und 775 getestet - ohne Erfolg.

Hi,

dein chmod Zeug hat überhaupt nichts damit zu tun! Du baust dir nur Sicherheitslücken ein wenn du 777 machst. Dateien sollten immer 644 haben und Verzeichnisse 755. Mit der 7 erlaubst du bei Dateien, dass sie ein bash script sein dürfen. Somit könnte man ein bash-script hochladen mit der Endung .jpg und es auf deinen Server, der mit 777 oder 755 für Dateien läuft, ausführen lassen.

Dein Problem ist das dein Webserver keine Weiterleitung macht, auf getimg.php wenn er das Bild nicht findet.

Schau mal ob das bei dir eingestellt ist:

RewriteCond %{REQUEST_URI} (/out/pictures/generated/)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.jpe?g|.gif|.png|.svg)$ getimg.php [NC]

Bist du von Apache auf Nnigx gewechselt oder ignoriert dein Apache die .htaccess datei? Oder das mod_rewrite.c ist bei deinem Apache nicht aktive.

VG
Tobi

1 Like

Die Rechte habe ich aus der Dokumentation von OXID übernommen (post install), daher bin ich hier nicht von einer möglichen Sicherheitslücke ausgegangen. Danke für den Hinweis und die Erklärung, ich werde die Rechte entsprechend einschränken.

Ein Wechsel von nginx hat nicht stattgefunden. Die .htaccess wurde wie gesagt vom Server übernommen.

Folgende Abweichung konnte ich feststellen:

RewriteCond %{REQUEST_URI} (\/out\/pictures\/generated\/)
RewriteRule (\.jpe?g|\.gif|\.png|\.svg)$ getimg.php [NC]

Ansonsten ist mod_rewrite.c geladen/aktiv und wurde vor meiner letzten chmod-Attacke auch in der Systemgesundheitsprüfung mit einem grünen Feld gekennzeichnet.

Da bei der Systemprüfung mod_rewrite mit grau gekennzeichnet ist:

Gibt es eine alternative Methode die Funktion des Moduls sicherzustellen?

Das heißt jetzt nicht dass es nicht funktioniert. Wenn du in deinem Shop

oxseo.php?mod_rewrite_module_is=off

aufrufst, dann sollte

mod_rewrite_on

als Antwort erscheinen.

Danke für den Tip. Das funktioniert, somit ist mod_rewrite im Shop aktiv. Aber Bilder werden trotzdem nicht generiert.

Diese zwei Zeilen solltest du hinzufügen. Da sie greifen wenn Bilder oder Verzeichnisse nicht auf rufbar sind.

Was du auch noch testen kannst. Ob OXID überhaupt ein Bild generieren kann und dabei schaust du ob es neue oxideshop.log einträge gibt.

Das hilft die zu unterscheiden ob es an dem Webserver Konfiguration liegt, an PHP oder am Filesystem.

Zuerst musst du auf der kaputtene Seite einen Bilder Pfad suchen. Sollte out/pictures/generated/ enthalten sein im Pfad…

http://test.oxideshop.de/out/pictures/generated/product/1/255_255_85/1672_p1.jpg

nach der Top-Level-Domain fügst du dieses ein /getimg.php?test= . Also:

http://test.oxideshop.de/getimg.php?test=out/pictures/generated/product/1/255_255_85/1672_p1.jpg

dadurch startest du die Bild Generierung manuel. Wenn du ein Bild siehst ist dein WebServer falsch konfiguriert. Wenn du kein Bild siehst. Versuche in den Log’s herauszufinden was schief gelaufen ist.

2 Likes

Also die Anleitung hat funktioniert.

Es wird tatsächlich ein Bild generiert, und in dem entsprechenden Ordner ( out/pictures/generated/product/1/540_340_75/ abgelegt. Der Error-Log erhält keinen weiteren Eintrag.

Danke für die Tipps die ich zu diesem Thema erhalten habe.

Nachdem ich die Verzeichnissrechte nochmals auf 775 gesetzt habe und die Zeilen in der .htaccess zurück auf den vorigen Stand gebracht habe funktioniert es seltsamerweise wieder.

Auf jeden Fall sind die Hinweise und Testanleitungen spitzenmäßig. :+1:

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.