Magento

PayPal Express Checkout und Unable to Place the order

Ich habe schon einige Probleme mit PayPal und Magento gelöst, aber folgendes war neu. Kunden konnten vom Warenkorb aus über den Check out with PayPal Button ganz normal die Bezahlung vornehmen. Nach erfolgreicher Bezahlung wurde jedoch die Fehlermeldung ” Unable to Place the order ” angezeigt und die Bestellung unterbrochen. Einige Kunden dachten etwas während der Bestellung falsch gemacht zu haben, und versuchten es gleich noch einmal. Nun wurde die Fehlermeldung ” Transaction refused because of an invalid argument. A successful transaction has already been completed for this token. ” angezeigt.

Kurz, beim ersten Versuch wurde das PayPal Konto bzw. die Kreditkarte des Kunden bereits belastet. Darum konnte beim zweiten Versuch die Transaction nicht noch einmal vorgenommen werden. Hinzu kam, dass trotz korrekten IPN Response im Backend keine Bestellung erstellt wurde. Der Grund war folgender:

2015-06-11T06:50:23+00:00 ERR (3):
exception 'PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '100000213' for key 'UNQ_SALES_FLAT_INVOICE_INCREMENT_ID''

1 2	2015-06-11T06:50:23+00:00 ERR (3): exception 'PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '100000213' for key 'UNQ_SALES_FLAT_INVOICE_INCREMENT_ID''

Bei solchen Fehlermeldungen lohnt es sich immer einen Blick in die EAV tables zu werfen. In meinem Fall wurde aus irgendeinem Grund die increment_last_id vom Typ sales/order_invoice geändert.

mysql> select * from eav_entity_store;
+-----------------+----------------+----------+------------------+-------------------+
| entity_store_id | entity_type_id | store_id | increment_prefix | increment_last_id |
+-----------------+----------------+----------+------------------+-------------------+
|               1 |              5 |        1 | 1                | 100000798         |
|               2 |              6 |        1 | 1                | 1212              |
|               3 |              8 |        1 | 1                | 100000028         |
+-----------------+----------------+----------+------------------+-------------------+
3 rows in set (0.01 sec)

mysql> select * from eav_entity_store;

+-----------------+----------------+----------+------------------+-------------------+

+-----------------+----------------+----------+------------------+-------------------+

| 1 | 5 | 1 | 1 | 100000798 |

| 2 | 6 | 1 | 1 | 1212 |

| 3 | 8 | 1 | 1 | 100000028 |

+-----------------+----------------+----------+------------------+-------------------+

3 rows in set (0.01 sec)

Die Länge der ID wird zudem in entity_model festgelegt, was in meinem Fall nicht übereinstimmte.

mysql> select entity_model, increment_pad_length from eav_entity_type where entity_type_id = 6;
+---------------------+----------------------+
| entity_model        | increment_pad_length |
+---------------------+----------------------+
| sales/order_invoice |                    8 |
+---------------------+----------------------+
1 row in set (0.00 sec)

mysql> select entity_model, increment_pad_length from eav_entity_type where entity_type_id = 6;

+---------------------+----------------------+

| entity_model | increment_pad_length |

+---------------------+----------------------+

| sales/order_invoice | 8 |

+---------------------+----------------------+

1 row in set (0.00 sec)

Da es keinen Grund gab die länge der Rechnungs Nummer zu ändern, habe ich diese wieder “recovered”.

mysql> UPDATE `eav_entity_store` SET `increment_last_id` = '200000001', `increment_prefix` = '2' WHERE `entity_type_id` = '6';

1	mysql> UPDATE `eav_entity_store` SET `increment_last_id` = '200000001', `increment_prefix` = '2' WHERE `entity_type_id` = '6';

Da ich zu diesem Zeitpunkt nicht wusste, wie viele Bestellungen schon vorgenommen wurden, habe ich ausserdem increment_prefix auf 2 gesetzt, einfach um sicher zu gehen, dass es keine weiteren Konflikte gibt. Vermutlich hätte ich auch die Rechnungsnummer einfach auf 100001000 setzen können, denn so viele Bestellungen sind definitiv nicht eingegangen.

mysql> select * from eav_entity_store;
+-----------------+----------------+----------+------------------+-------------------+
| entity_store_id | entity_type_id | store_id | increment_prefix | increment_last_id |
+-----------------+----------------+----------+------------------+-------------------+
|               1 |              5 |        1 | 1                | 100000802         |
|               2 |              6 |        1 | 2                | 200000001         |
|               3 |              8 |        1 | 1                | 100000028         |
+-----------------+----------------+----------+------------------+-------------------+
3 rows in set (0.00 sec)

mysql> select * from eav_entity_store;

+-----------------+----------------+----------+------------------+-------------------+

+-----------------+----------------+----------+------------------+-------------------+

| 1 | 5 | 1 | 1 | 100000802 |

| 2 | 6 | 1 | 2 | 200000001 |

| 3 | 8 | 1 | 1 | 100000028 |

+-----------------+----------------+----------+------------------+-------------------+

3 rows in set (0.00 sec)

Wie auch immer, das Problem mit den PayPal Express Bezahlungen wurde damit gelöst und funktioniert auch zwei Wochen nach dem Change noch.

Magento und max_input_vars

Es gibt Tage als Magento Entwickler bei denen man einfach nur verzweifelt, und zwar dann, wenn man komplexe Produkte oder Kategorien erstellen möchte. In den letzten zwei Wochen habe ich mich gleich mit zwei solchen Problemen beschäftigt, bei denen leider keine Fehlermeldung (system.log, exception.log etc.) zu sehen war welche zumindest ein bisschen weiterhelfen würde. Konkret geht es um die Standardeinstellung in der php.ini.

; How many GET/POST/COOKIE input variables may be accepted
; max_input_vars = 1000

1 2	; How many GET/POST/COOKIE input variables may be accepted ; max_input_vars = 1000

Diese Standardeinstellung führt dazu, dass komplexe Formulare im Admin Panel zwar Erfolgreich abgeschickt werden können, jedoch nicht alles vom Server akzeptiert wird. Will man also Kategorien mit mehr als 1000 Produkten speichern oder 100 bis 150 Bundle Items zu einem Bundle Produkt hinzufügen, gibt es hier möglicherweise Probleme.

Das Problem kann gelöst werden indem man den Wert für max_input_vars in der php.ini oder in der .htaccess auf 2000 oder mehr erhöht, aber nicht unbedingt mehr als benötigt.

<IfModule mod_php5.c>
    php_value max_input_vars 5000
</IfModule>

php_value max_input_vars 5000

</IfModule>

Das ganze kann man mit LocationMatch auf das Admin Panel beschränken.

<LocationMatch "(index\.php/)?admin/">
    <IfModule mod_php5.c>
        php_value max_input_vars 5000
    </IfModule>
</LocationMatch>

php_value max_input_vars 5000

</IfModule>

</LocationMatch>

Malware in Bilddateien finden

Es ist ein Alptraum. Die Liveumgebung deines Kunden wurde gehackt und du weisst nicht, wie genau und welche Daten gestolen wurden. Schnell muss also untersucht werden, wo die Schwachstelle liegt um solche Angriffe in Zukunft besser abzufangen. Natürlich gibt es verschiedene Wege sich Zugang zu einer Liveumgebung zu verschaffen. In diesem Post möchte ich nur kurz darauf eingehen, wie mittels Bilddateien beliebiger Code eingeschleust werden kann.

Wie auf Snapfast und Sucuri beschrieben, kann beliebiger Code in EXIF von Bilddateien untergebracht werden. Oft genügt schon ein einfaches Script um einen neuen Administrator account zu erstellen. Alles weitere passiert dann im Hintergrund, oft unerkannt.

Leider hilft ein svn status oder git status nicht um geänderte Dateien zu erkennen, denn oft sind Verzeichnisse wie /media/ nicht versioniert.

Hier ein einfacher Befehl wie du solche Bilddateien mit “find” aufspüren kannst.

$ cd /var/www/{{{MAGENTO}}}/
$ find . -iregex '.*\.\(jpg\|gif\)' -exec grep -o -P 'base64_decode' {} \;

1 2	$ cd /var/www/{{{MAGENTO}}}/ $ find . -iregex '.*\.$jpg\\|gif$' -exec grep -o -P 'base64_decode' {} \;

Sollten Dateien auf dem Produktivsystem infiziert sein, bekommst du folgendes Suchergebnis.

Binary file ./media/test.jpg matches

1	Binary file ./media/test.jpg matches

5 praktische Beispiel für die tägliche Arbeit mit Magento

1. Sicherung von media/catalog

So erstellst du eine Sicherung von media/catalog ohne dem /cache/ Verzeichnis.

$ cd /var/www/{{{MAGENTO}}}/media/
$ tar -czf ~/catalog.tar.gz catalog --exclude 'catalog/product/cache/*'

1 2	$ cd /var/www/{{{MAGENTO}}}/media/ $ tar -czf ~/catalog.tar.gz catalog --exclude 'catalog/product/cache/*'

Das gleiche mit dem aktuellen Datum im Dateinamen.

$ tar -czf ~/"catalog_$(date '+%Y%m%d').tar.gz" catalog --exclude 'catalog/product/cache/*'

1	$ tar -czf ~/"catalog_$(date '+%Y%m%d').tar.gz" catalog --exclude 'catalog/product/cache/*'

2. Dateien ohne Berechtigungen für Apache

So findest du Dateien welche nicht die nötigen Berechtigungen für Apache besitzen. Das macht Sinn wenn du Berechtigungsprobleme früh erkennen möchtest. Zum Beispiel Schreib- oder Leseberechtigungen bei Dateien oder Verzeichnissen für diverse Upload Funktionen.

$ cd /var/www/{{{MAGENTO}}}/
$ find . \! -group www-data \! -user www-data

1 2	$ cd /var/www/{{{MAGENTO}}}/ $ find . \! -group www-data \! -user www-data

3. SQL / CSV Dateien im Projektverzeichnis

Manchmal ist es keine gute Idee Datenbank Sicherungen oder andere exportierte Dateien mit sensiblen Informationen im Projektverzeichnis abzulegen. Je nach Sicherheitseinstellungen können solche Dateien von dritte heruntergeladen werden. Um mögliche Sicherungen auf dem Produktivsystem auffinden zu können, brauchst du nur ein einfachen ” find ” Befehl mit der Option ” iregex “.

$ cd /var/www/{{{MAGENTO}}}/
$ find -iregex '.*\.\(sql\|tar\|gz\|zip\|csv\)'

1 2	$ cd /var/www/{{{MAGENTO}}}/ $ find -iregex '.*\.$sql\\|tar\\|gz\\|zip\\|csv$'

4. Report Dateien der letzten 24 Stunden

$ cd /var/www/{{{MAGENTO}}}/var/report/
$ find . -type f -ctime -1

1 2	$ cd /var/www/{{{MAGENTO}}}/var/report/ $ find . -type f -ctime -1

Hier sind weitere Optionen fuer ” -ctime “.

# find files created greater than 24 hours ago
find . -type f -ctime +0

# find files created between now and 1 day ago
# (i.e., in the past 24 hours only)
find . -type f -ctime 0

# find files created less than 1 day ago
find . -type f -ctime -1

# find files created between 24 and 48 hours ago
find . -type f -ctime 1

# find files created more than 48 hours ago
find . -type f -ctime +1

# find files created greater than 24 hours ago

find . -type f -ctime +0

# find files created between now and 1 day ago

# (i.e., in the past 24 hours only)

find . -type f -ctime 0

# find files created less than 1 day ago

find . -type f -ctime -1

# find files created between 24 and 48 hours ago

find . -type f -ctime 1

# find files created more than 48 hours ago

find . -type f -ctime +1

5. Logdateien leeren

Schnell wachsende Logdateien wie system.log oder exception.log können eine Ursache für einen Serverausfall sein. Mit Hilfe von ” truncate ” kannst du log Dateien ohne Risiko auf deinem Produktivsystem leeren.

$ cd /var/www/{{{MAGENTO}}}/var/log
$ truncate -s 0 system.log

1 2	$ cd /var/www/{{{MAGENTO}}}/var/log $ truncate -s 0 system.log

Wenn du nicht alles entfernen möchtest, kannst du auch einen Teil für die Fehlersuche behalten.

$ truncate -s 10M system.log

1	$ truncate -s 10M system.log

Praktische Beispiele für deine Magento Logdatei Analyse

Verbessere deine wöchentliche Logdatei Analyse mit ein paar einfachen ” grep ” Befehlen. Verwende diese vor jedem Rollout um sicher zu gehen, dass dein Code einwandfrei funktioniert und keine Fehlermeldungen generiert. Um bei grösseren Logdateien die Übersicht zu behalten, kannst du mit ” tail ” die letzten 1000 Zeilen überprüfen, oder zunächst einfach mit ” wc -l ” schauen wie hoch die Anzahl an Fehlermeldungen überhaupt ist.

Zähle die Resultate mit ” wc -l ” am Ende.

$ grep -oi 'undefined index' system.log | wc -l

1	$ grep -oi 'undefined index' system.log \| wc -l

Zeige die letzten 1000 Zeilen von system.log mit ” tail -n 1000 ” an.

$ tail -n 1000 system.log | grep -i 'undefined index' system.log

1	$ tail -n 1000 system.log \| grep -i 'undefined index' system.log

1. System.log

1.1 Zugriffe auf ein Array mit einem Key welcher nicht existiert

$ grep -i 'undefined index' system.log

1	$ grep -i 'undefined index' system.log

1.2 Zugriff auf eine Variable welche nicht definiert ist

$ grep -i 'undefined variable' system.log

1	$ grep -i 'undefined variable' system.log

1.3 Debug Ausgaben mit Mage::log() generiert

$ grep -i 'debug' system.log

1	$ grep -i 'debug' system.log

1.4 Diverse fehlgeschlagene Versuche eine Datei oder ein Verzeichnis zu erstellen oder manipulieren

$ grep -i 'permission denied' system.log

1	$ grep -i 'permission denied' system.log

1.5 Falsch definierte oder nicht existierende Template Dateien

$ grep -i 'not valid template file' system.log

1	$ grep -i 'not valid template file' system.log

1.6 Fehler bei Zugriff auf ein Objekt

$ grep -i 'trying to get property of non-object' system.log

1	$ grep -i 'trying to get property of non-object' system.log

1.7 Parameter an eine Funktion nicht korrekt übergeben

$ grep -i 'missing argument' system.log

1	$ grep -i 'missing argument' system.log

1.8 Ungültige Variable an eine Schleife übergeben

$ grep -i 'invalid argument supplied' system.log

1	$ grep -i 'invalid argument supplied' system.log

Alles mit einmal finden:

$ cat system.log | egrep -i '(debug|notice: undefined|permission denied|not valid template file|trying to get property of non-object|missing argument)'

1	$ cat system.log \| egrep -i '(debug\|notice: undefined\|permission denied\|not valid template file\|trying to get property of non-object\|missing argument)'

2. Exception.log

2.1 Generelle Probleme mit XML Dateien

$ grep -i 'xml schema' exception.log

1	$ grep -i 'xml schema' exception.log

2.2 Spezifische Probleme mit dem Authorize.net Gateway

$ grep -i 'paygate.*gateway' exception.log

1	$ grep -i 'paygate.*gateway' exception.log

2.3 Spezifische Probleme mit dem PayPal Gateway

$ grep -i 'paypal.*gateway' exception.log

1	$ grep -i 'paypal.*gateway' exception.log

2.4 Generelle Probleme mit CURL

$ grep -i 'curl' exception.log

1	$ grep -i 'curl' exception.log

Alle mit einmal finden:

$ cat exception.log | egrep -i '(xml schema|paygate.*gateway|paypal.*gateway|curl)'

1	$ cat exception.log \| egrep -i '(xml schema\|paygate.gateway\|paypal.gateway\|curl)'

3. Reports

Report Dateien auf der Konsole zu überprüfen ist mühsam. Mit den folgenden Befehlen kannst du schnell die neusten 10 Reports mit einmal durchsuchen.

3.1 MySQL Verbindungen

$ ls -1t | head -10 | xargs grep -i 'mysql server' -sl

1	$ ls -1t \| head -10 \| xargs grep -i 'mysql server' -sl

3.2 Invalid config field

$ ls -1t | head -10 | xargs grep -i 'invalid config field' -sl

1	$ ls -1t \| head -10 \| xargs grep -i 'invalid config field' -sl

3.3 Unable to read response

$ ls -1t | head -10 | xargs grep -i 'unable to read response' -sl

1	$ ls -1t \| head -10 \| xargs grep -i 'unable to read response' -sl

3.4 External urls redirect

$ ls -1t | head -10 | xargs grep -i 'external urls redirect' -sl

1	$ ls -1t \| head -10 \| xargs grep -i 'external urls redirect' -sl

Alle mit einmal finden:

ls -1t | head -10 | xargs  egrep -i '(mysql server|invalid config field|unable to read response|external urls redirect)' -sl

1	ls -1t \| head -10 \| xargs egrep -i '(mysql server\|invalid config field\|unable to read response\|external urls redirect)' -sl

4. Apache error logs

4.1 Fehlende Dateien im Projektverzeichnis

$ tail -n 1000 /var/log/httpd/{virtualhost}-error_log | grep -i 'file does not exist'

1	$ tail -n 1000 /var/log/httpd/{virtualhost}-error_log \| grep -i 'file does not exist'

Geplante Tasks für Apache Benutzer einrichten

Geplante Tasks (Cron jobs) für PHP Applikationen sollten einem spezifischen Benutzer ohne root Berechtigungen zuordnet werden, also zum Beispiel www-data. So verhinderst du unter anderem, dass bei einem System Update die geplanten Tasks für root überschrieben werden.

1. Apache user suchen

Den Benutzer welcher von Apache verwendet wird, kannst du aus der Prozessliste entnehmen.

$ ps axo user,group,comm | egrep '(apache|httpd)'
root     root     apache2
www-data www-data apache2

$ ps axo user,group,comm | egrep '(apache|httpd)'

root root apache2

www-data www-data apache2

2. Tab editieren

Editiere den crontab mit der Option -u und dem Benutzer welcher von Apache verwendet wird. Dieser Befehlt erstellt eine Benutzerspezifische Datei in /var/spool/cron/crontabs/.

$ crontab -u www-data -e

1	$ crontab -u www-data -e

Füge deinen Cronjob ein und speichere alle Änderungen mit CTRL-O.

# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command
*/5 * * * * /bin/sh /var/www/{{{magento}}}/cron.sh

# For example, you can run a backup of all your user accounts

# at 5 a.m every week with:

# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/

# For more information see the manual pages of crontab(5) and cron(8)

# m h dom mon dow command

*/5 * * * * /bin/sh /var/www/{{{magento}}}/cron.sh

3. Syslog überprüfen

Anschliessend kannst du schauen ob dein Cronjob korrekt ausgeführt wird.

$ grep CRON.*\(www-data\) /var/log/syslog

1	$ grep CRON.*$www-data$ /var/log/syslog

Table is marked as crashed and should be repaired

Nicht gleich verzweifeln. Die folgende Fehlermeldung kannst du wie in diesem Artikel beschrieben recht schnell beheben.

SQLSTATE[HY000]: General error: 145 Table './magento/log_visitor_info' is marked as crashed and should be repaired

1	SQLSTATE[HY000]: General error: 145 Table './magento/log_visitor_info' is marked as crashed and should be repaired

Es gibt verschiedene Ursachen für eine beschädigte MySQL Tabelle. Die häufigsten sind:

Im schlimmsten Fall defekte Hardware
Plötzlicher Server Neustart ( Stromausfall )
Reset (ACPI shutdown)

In den meisten Fällen kann eine defekte MySQL Tabelle in der Konsole wieder repariert werden.

mysql> repair table log_visitor_info;
+-----------------------+--------+----------+----------+
| Table                 | Op     | Msg_type | Msg_text |
+-----------------------+--------+----------+----------+
| magento.log_visitor_info | repair | status   | OK       |
+-----------------------+--------+----------+----------+
1 row in set (0.54 sec)

mysql> repair table log_visitor_info;

+-----------------------+--------+----------+----------+

+-----------------------+--------+----------+----------+

+-----------------------+--------+----------+----------+

1 row in set (0.54 sec)

Das sieht ziemlich einfach aus, trotzdem solltest du dir 5 Minuten Zeit nehmen und deine Datenbank vorher sichern, denn möglicherweise sind noch andere Tabellen betroffen.