Jump to content
xt:Commerce Community Forum

Ipayment Patch funktioniert nicht !


comanche3

Recommended Posts

Also irgendwie klappt das bei mir mit dem Patch nicht. Ich habe alles nach Readme so gemacht wie geschrieben, abe er landet immer wieder in der checkout_payment.php. Das schlimmste, er bucht das Geld sogar bei den Kunden ab, erstellt aber keine Bestellung.

Oben in der checkout_payment.php. steht danach

Bei der Verarbeitung Ihrer Kreditkartendaten ist ein Fehler aufgetreten:

das war´s keine Fehlerangabe

Link to comment
Share on other sites

Bei uns war der Fehler auch.

Das Problem ist, dass das neue iPayment-Modul nach der Rückkehr des Kunden von iPayment den Security Hash überprüfen will.

Dabei speichert das Modul den Wert der Bestellung (Variable amount) vor dem senden des Users an iPayment in der Session - allerdings in unserem Fall nicht richtig, weswegen es auf der checkout_confirmation auch immer eine Fehlermeldung gab - ich weiß nicht ob das daran liegt, das bei uns irgendeine Datei veraltet ist o.ä., jedenfalls lautet die Fehlermeldung:

Warning: Cannot use a scalar value as an array in (...)/includes/modules/payment/ipayment.php on line 142

Jeder, bei dem diese Meldung kommt, dürfte die entsprechenden Probleme haben.

Nachzuschauen übrigens in der Tabelle payment_ipayment_log, dort steht dann jeweils, dass der Security code nicht übereinstimmt.

Und das ist das Problem - bei iPayment geht alles gut, er schickt den User mit einer positiven Rückmeldung an den Shop, und trotzdem produziert das iPayment-Modul den Fehler.

Mein Fix - wobei ich natürlich nicht weiß, ob das andere Probleme nach sich zieht!

Datei zu editieren: includes/modules/payment/ipayment.php

Folgende Zeilen auskommentieren:

if (empty($_SESSION[$this->code]->amount) || (int)$_GET['trx_amount'] != $_SESSION[$this->code]->amount)
$errorMsg = 'Amount doesn\'t match.';[/PHP]

[i]an zwei Stellen:[/i]

[PHP]unset($_SESSION[$this->code]->amount);[/PHP]

[PHP]$_SESSION[$this->code]['amount'] = round($amount * 100, 0);[/PHP]

Die Zeile

[PHP]$hash = md5(MODULE_PAYMENT_IPAYMENT_USER_ID . $_SESSION[$this->code]->amount . $trx_currency . $_GET['ret_authcode'] . $_GET['ret_booknr'] . MODULE_PAYMENT_IPAYMENT_SECURITY_KEY);[/PHP]

ersetzen durch

[PHP]$hash = md5(MODULE_PAYMENT_IPAYMENT_USER_ID . $_GET['trx_amount'] . $trx_currency . $_GET['ret_authcode'] . $_GET['ret_booknr'] . MODULE_PAYMENT_IPAYMENT_SECURITY_KEY);[/PHP]

Erklärung: da die wichtigen Werte (wie zB der Wert der Bestellung = amount) ohnehin durch den Security Code nochmals überprüft werden (indem ein md5-Hash gebildet wird über diese wichtigen Werte, der den von euch selbst vergebenen und Dritten damit unbekannten Security Code enthält), kann der Wert "amount" genausogut auch aus dem $_GET-Parameter "trx_amount" ausgelesen werden. Manipulation - m.E., ohne Gewähr - trottdem nicht möglich.

Link to comment
Share on other sites

Die Analyse bezüglich der Session ist korrekt. Der Wert "amount" wird auf manchen Systemen nicht korrekt in der Session gespeichert bzw. kann nicht abgerufen werden, nachdem der Kunde von ipayment zurück in den Shop geleitet wird.

Falsch ist jedoch die Annahme, dass $_SESSION['amount'] und $_GET['trx_amount'] zwingend identisch sind. Wird diese Überprüfung rausgenommen können Transaktionsdaten möglicherweise manipuliert werden.

Link to comment
Share on other sites

Glaube ich nicht, da ja sowohl beim Senden an iPayment als auch hinterher wenn der User zurückkommt mit dem Security Key der md5-Hash generiert und überprüft wird.

Würde es reichen, wenn man einfach anstatt dem iPayment-Session-Objekt eine eigene Sessionvariable verwendet?

Also $_SESSION[$this->code]->amount ersetzen durch beispielsweise $_SESSION[$this->code.'amount']

Link to comment
Share on other sites

Scheinbar gibt es nach der Installation des Patchs auf einigen PHP4-Systemen Probleme. Wir haben die beiden Module (KK + ELV) modifiziert, so dass der Fehler nicht mehr auftreten sollte.

Bevor wir diese Version veröffentlichen, hätten wir dazu gerne Feedback von Shop-Betreibern, bei denen das Problem bisher auftritt.

Bitte PM mit E-Mail Adresse an mich dann wird die neue Version umgehend zugeschickt.

Link to comment
Share on other sites

Das hier im Forum beschriebene Problem tritt nur in manchen PHP-Konfigurationen auf. Eine leicht modifizierte Version des Patches (v1.0.1) soll das Problem beheben. Der Download wird vom Support zur Verfügung gestellt werden.

Danke für die zahlreichen Rückmeldungen der Shop-Administratoren und die guten Hinweise (u.A. von Josef Geisberger).

------------------------------------

Björn Kraus

Phoenix Medien GmbH & Co. KG

http://www.phoenix-medien.de

Link to comment
Share on other sites

Hallo Zusammen,

ich habe noch ein anderes Problem: Nach genauer Installation des Patches, können die AGB nicht mehr akzeptiert werden obwohl der enstpr. Haken gesetzt wurde.

Es kommt immer die Meldung:

* Sofern Sie unsere Allgemeinen Geschäftsbedingungen nicht akzeptieren, können wir Ihre Bestellung bedauerlicherweise nicht entgegennehmen!

Kann mir jemand auf die Sprünge helfen wo und wie ich diesen Fehler beheben kann?

1000 Dank

Link to comment
Share on other sites

... ja - so sieht das Stück code aus:

if (DISPLAY_CONDITIONS_ON_CHECKOUT == 'true') {

if ($_REQUEST['conditions'] == false) {

$error = str_replace( '\n', '<br />', ERROR_CONDITIONS_NOT_ACCEPTED );

xtc_redirect(xtc_href_link(FILENAME_CHECKOUT_SHIPPING, 'error_message=' . urlencode($error),'SSL', true, false));

}

}

unglaublich, wie schnell hier eine Antwort kommt...

Link to comment
Share on other sites

... mir ist gerade aufgefallen, dass in der Originaldatein ein Leerzeichen vor dem letzten Zeichen steht - kann das etwas bewirken?

Original-Datei:if ($_POST['conditions'] == false){

Neue Version:if ($_REQUEST['conditions'] == false) {

UPDATE: Das war es leider nicht - habe es gerade ausprobiert.

Link to comment
Share on other sites

Moin,

ja, der gleiche Key ist (jetzt) 100% drin, copy&paste da kann nix schiefgegangen sein... sind auch keine Umlaute/Sonderzeichen o.ä. drin.

Trotzdem: Wenn ich mit 4111111111111111 und Prüfnummer 123 einen Test mache kommt:

"The card type is not processed by the authorization center"

Ob das bei ner "echten" Karte auch passiert weiß ich nicht aber das es scheiße denn es ist CeBIT!!

Link to comment
Share on other sites

joa ich dachte dass man es damit testen kann, ohne in den Simulationsmodus zu gehen. Wir versuchen bereits, eine CC Nummer aufzutreiben...

Ist der block so korrekt in der Checkout_confirmation.php drin (Zeile 202):


$smarty->assign('PAYMENT_METHOD', constant(MODULE_PAYMENT_ . strtoupper($order->info['payment_method']) . _TEXT_TITLE));
}

if (isset($_GET['payment_error']) && is_object(${$_GET['payment_error']}) && ($error = ${$_GET['payment_error']}->get_error()))
$smarty->assign('error', $error['title'].'<br />'.htmlspecialchars($error['error']));

$smarty->assign('PAYMENT_EDIT', xtc_href_link(FILENAME_CHECKOUT_PAYMENT, '', 'SSL'));
[/PHP]

Die Erklärung war da etwas schwammig in der Anleitung, denn "nach "$smarty->assign('PAYMENT_METHOD'..." macht nur sinn, wenn man weiß wo "..." aufhört ^^

Link to comment
Share on other sites

Also ist meine Checkout_confirmation.php falsch, da der Block mit in die geschweifte Klammer rein muss?

Edit: Ja, scheint dass das der Fehler war. Habe gerade einen Test-Kauf getätigt und danach ging es!

Wie wärs nächtesmal einfach mit "innerhalb der geschweiften Klammern" oder "außerhalb" schreiben? ;-) Denn wenn ich ein "nach" Angebe, dann aber nicht sage wo meine "..." enden ist das sinnfrei ^^

Link to comment
Share on other sites

  • 2 months later...

wie ist der aktuelle Stand mit dem Patch, läuft der jetzt, bzw. mit welchen Änderungen?

Der Patch, so wie er unter http://www.xt-commerce.info/index.php?_m=downloads&_a=viewdownload&downloaditemid=2&nav=0,3,4 runtergeladen werden kann, läuft auf allen uns bekannten Systemen ohne Probleme.

Ist es überhaupt ratsam umzusteigen oder kann man auch noch den alten lassen?

Der Patch behebt gravierende Sicherheitslücken im ipayment-Modul und sorgt dafür, dass das Modul PCI-konform läuft. Mit dem alten Modul, das nicht PCI-konform ist, gefährdet man u.U. seinen Kreditkartenakzeptanzvertrag.

Weitere Informationen finden sich auch im c't Artikel "Zechpreller", den man sich als PDF unter http://www.phoenix-medien.de/news/artikel/sicherheitsluecke-in-xtcommerce-wird-von-phoenix-medien-geschlossen.html runterladen kann.

Viele Grüße

Björn Kraus

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
  • Create New...