comanche3 Posted February 27, 2008 Report Share Posted February 27, 2008 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 More sharing options...
geisberger Posted February 27, 2008 Report Share Posted February 27, 2008 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 More sharing options...
geisberger Posted February 27, 2008 Report Share Posted February 27, 2008 ... alternativ die includes/modules/payment/ipayment.php durch diese ersetzen. Habe die Änderungen in der Datei am Anfang jeweils mit "// FIX" und einer kleinen Erklärung versehen.ipayment.php.txt Link to comment Share on other sites More sharing options...
Espresso-Trinker Posted February 27, 2008 Report Share Posted February 27, 2008 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 More sharing options...
geisberger Posted February 27, 2008 Report Share Posted February 27, 2008 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 More sharing options...
geisberger Posted February 27, 2008 Report Share Posted February 27, 2008 Wie schlecht is das abgesehen davon eigentlich, dass man sich bei einem SECURITY-PATCH mit solchen Fehlern beschäftigen muss? Link to comment Share on other sites More sharing options...
comanche3 Posted February 27, 2008 Author Report Share Posted February 27, 2008 Mit den Änderungen geht´s ! Ich werde es jetzt erstmal so laufen lassen und die Abbuchungsmails im Auge behalten. Besser wie mit dem alten Ipayment ist es so wohl auf jeden Fall. Link to comment Share on other sites More sharing options...
Espresso-Trinker Posted February 27, 2008 Report Share Posted February 27, 2008 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 More sharing options...
geisberger Posted February 27, 2008 Report Share Posted February 27, 2008 Habe nun eine Version gebaut, in der der Wert von amount in einer zusätzlichen Session-Variablen gespeichert wird. Reicht das nun aus?ipayment.php.txt Link to comment Share on other sites More sharing options...
DaRu Posted February 28, 2008 Report Share Posted February 28, 2008 Gibt es hier auch eine Stellungnahme vom offiziellen "Support"? Wenn ich mir das hier alles so durchlese, werde ich vorerst den Patch nicht aufspielen .... Link to comment Share on other sites More sharing options...
Espresso-Trinker Posted February 28, 2008 Report Share Posted February 28, 2008 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 More sharing options...
badestrand Posted February 28, 2008 Report Share Posted February 28, 2008 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 More sharing options...
Espresso-Trinker Posted February 28, 2008 Report Share Posted February 28, 2008 Hast du $_POST['conditions'] durch $_REQUEST['conditions'] ersetzt? Link to comment Share on other sites More sharing options...
badestrand Posted February 28, 2008 Report Share Posted February 28, 2008 ... 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 More sharing options...
badestrand Posted February 28, 2008 Report Share Posted February 28, 2008 ... 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 More sharing options...
Espresso-Trinker Posted February 28, 2008 Report Share Posted February 28, 2008 Der Checkout in deinem Shop ist stark verändert. Die Änderungen in der Anleitung beziehen sich auf den unveränderten Shop 3.04 SP2.1 ... Link to comment Share on other sites More sharing options...
marcobasse Posted March 3, 2008 Report Share Posted March 3, 2008 Moin, also ich habe den Patch des Patches installiert und es funktioniert immer noch nicht! Es kommen Kreditkartenzahlungen rein aber im Shop werden keine Bestellungen angelegt!! Ich schalte Kreditkartenzahlung jetzt erstmal ab... Link to comment Share on other sites More sharing options...
Espresso-Trinker Posted March 3, 2008 Report Share Posted March 3, 2008 Bitte prüfen, ob in der ipayment-Applikation der selbe Security Key für die Applikation hinterlegt ist. Link to comment Share on other sites More sharing options...
marcobasse Posted March 4, 2008 Report Share Posted March 4, 2008 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 More sharing options...
Espresso-Trinker Posted March 4, 2008 Report Share Posted March 4, 2008 Es wäre tatsächlich blöd, wenn dein Acquirer die Testnummern akzeptieren würde ... Vielleicht fragst du einen Kollegen, ob er nicht eine Testbestellung bei dir mit einer richtigen Kreditkarte machen kann Link to comment Share on other sites More sharing options...
marcobasse Posted March 4, 2008 Report Share Posted March 4, 2008 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 More sharing options...
Espresso-Trinker Posted March 4, 2008 Report Share Posted March 4, 2008 http://www.xt-commerce.com/forum/showpost.php?p=286383&postcount=4 Link to comment Share on other sites More sharing options...
marcobasse Posted March 4, 2008 Report Share Posted March 4, 2008 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 More sharing options...
Sebas80 Posted May 4, 2008 Report Share Posted May 4, 2008 Hallo Kollegen, wie ist der aktuelle Stand mit dem Patch, läuft der jetzt, bzw. mit welchen Änderungen? Ist es überhaupt ratsam umzusteigen oder kann man auch noch den alten lassen? Danke und Gruß Sebas80 Link to comment Share on other sites More sharing options...
Espresso-Trinker Posted May 5, 2008 Report Share Posted May 5, 2008 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 More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.