Notfall

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.

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

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.