Hallo liebe Community, ich benötige leider Hilfe und hoffe dass jemand eine Lösung für mich hat. Ich habe mit ein Zahlungsmodul programmieren lassen um Kreditkarten Zahlungen über meine lokale Hausbank akzeptieren zu können. Die Zahlungsabwicklung ist nicht "in Frame oder in Page" sondern der Gambio Shop leitet meine Kunden auf die Website der Bank weiter um dort die Zahlung auszuführen und nach Zahlung leitet die Website meiner Bank die Kunden wieder zurück in meinen Gambio Shop. Das Modul hat unter GX2, GX3 und einige Versionen von GX4 (natürlich ab und zu mal anpassungen) immer funktioniert. Nun funktioniert es nicht mehr, weil sich etwas im Gambio Code geändert hat. Somit habe ich ein Update in Auftrag geben lassen aber der Programmierer ist mit seinem Latain am Ende. Es gibt folgendes Problem: Nachdem der Kunde von der Seite wieder zurück zum Gambio Shop geleitet wird, ist er plötzlich ausgeloggt. Der Programmierer hat daher folgende Frage: "You might ask Gambio what procedure to follow for accepting the banks POST to the checkout process page or to a callback page. At the moment I see that the POST is reset by Gambio and that the customer gets logged out." davor hatte er noch geschrieben gehabt: "I tried to rebuild the extension this weekend but I did not manege to get it working. The new version of Gambio has some kind of protection that when values are posted back to the site (like your bank does) the customer is logged out. I searched the available documentation and files, but unfortunately I did not find any instructions on how adjust the payment module for this." Ich würde mich sehr freuen wenn Ihr mir die Lösung sagen könntet, so dass ich es dem Programmierer sagen kann damit er dass Modul auf der aktuellen Gambio Version 4.2.1.0 wieder zum laufen bekommt. In der Entwickler Dokumentation finde ich leider keine Antwort. Würde mich über Hilfe freuen, Danke
Dass der Kunde in dieser Situation aus seiner Session fliegt (also ausgeloggt wird), ist eher kein beabsichtigtes Verhalten. Und ich kann mir auch ad hoc nicht vorstellen, wie es überhaupt dazu kommt, unter normalen Umständen. Nur ein Szenario fällt mir gerade ein: Wenn der Rückleitungs-URL nicht zur normalen Shopadresse passt (z.B. „http://www.dein-shop.tld/checkout_process.php“ statt „https://www.dein-shop.tld/checkout_process.php“), würde das ins Auge gehen.
Hallo Marco, vielen Dank für deine Antwort. Das Problem mit der Rückleitungs-URL ist auszuschließen. Er sagte folgendes: Basically I just need to know if the return url should contain a specific parameter like a token, or if the callback script need some additional code to avoid that the post from the bank is considered as an attack. So wie ich verstehe meint er, dass man aus dem Shop ausgeloggt wird da der Shop etwas als "attacke" sieht weil ggf. parameter wie ein token oder callback script fehlen. Es ist anzumerken dass ich dieses Modul seit 2015 im Einsatz habe und es immer funktioniert hatte nachdem hin und wieder mal einige Anpassungen durchgeführt wurden. Aber irgendwas hat sich in den letzten Versionen geändert dass er es nicht mehr zum laufen bekommt. Weißt du vielleicht ob es parameter wie token oder callback script gibt? Oder hast du ggf. noch eine andere Idee? Danke
Wie kommt er denn überhaupt auf den Gedanken, dass da etwas als Attacke gewertet wird? Generell: Es gibt da keinen Token, Schlüssel oder sonstiges. Nur das Session-Cookie muss halt erhalten bleiben, sonst fliegt man raus.
Hallo Marco, vielleicht habe ich es auch falsch verstanden. Hilft dir eventuell folgendes: The POST to (Link nur für registrierte Nutzer sichtbar.) is redirected (302 GET) to (Link nur für registrierte Nutzer sichtbar.) and the POST parameters are emptied. (Link nur für registrierte Nutzer sichtbar.) The result is that the customer is logged out and sees an empty cart. Also posting to a callback URL like (Link nur für registrierte Nutzer sichtbar.) after the require_once 'includes/application_top.php'; in the code the POST parameters are emptied and the customer session is emptied;
Das ist gerade alles etwas Glaskugelei. – In dem Screenshot sieht man, dass da eine Session-ID (GXsid) im Query String steckt. Das könnte irgendwas durcheinander bringen, das unterstützen wir schon seit Langem nicht mehr, die Session-ID gehört ins Cookie. Der normale Ablauf in einem Zahlungsmodul (mit tmpOrders == true) ist, dass checkout_payment() eine Weiterleitung zu einem externen Dienstleister ausführt und dabei die Rücksprungadresse auf die checkout_process.php setzt. Der Ablauf ist dann checkout_confirmation.php --POST--> checkout_process.php --GET--> Payment-Dienstleister --GET/POST--> checkout_process.php --> checkout_success.php
Hallo Marco, nochmals vielen Dank für deine Mühe, ich weiß die Hilfe wirklich sehr zu schätzen da ich sonst nicht weiter wüsste was zu tun ist. Ich habe alle Infos weitergegeben, aber anscheinend verfolgt mich das Unglück: It makes no difference when using the session parameter or not in the return URL. As soon as POST variables are received they are reset to an empty array after the application_top.php inclusion and the customer session is gone. When using GET parameters instead of POST parameters, there is no problem. [customers_status] => Array ( [customers_status_id] => 1 [customers_status_name] => Gast [customers_status_image] => guest_status.gif [customers_status_discount] => 0.00 [customers_status_public] => 0 [customers_status_min_order] => 0 [customers_status_max_order] => 0 [customers_status_ot_discount_flag] => 0 [customers_status_ot_discount] => 0.00 [customers_status_graduated_prices] => 1 [customers_status_show_price] => 1 [customers_status_show_price_tax] => 1 [customers_status_add_tax_ot] => 1 [customers_status_payment_unallowed] => [customers_status_shipping_unallowed] => [customers_status_discount_attributes] => 0 [customers_fsk18_purchasable] => 0 [customers_fsk18_display] => 1 [customers_status_write_reviews] => 0 [customers_status_read_reviews] => 1 ) Danke
Hallo, ich kann für nichts garantieren aber wir hatten mal ein ähnliches Problem wo wir nicht verstehen konnten warum der POST Body einfach verschwindet. Es hatte sich dabei rausgestellt das der Shop ohne www in den Konfigurationsdateien hinterlegt war, allerdings uns eine URL mit dem www übermittelt wurde. Dann kam es wenn wir auf die Shop URL mit www gingen immer zu einem redirect dank der .htaccess und diese hat dann daraus einen GET gemacht und den Body geschluckt. Ich konnte oben bei den URLs die du genannt hast zwar keinen Unterschied erkennen, aber vielleicht hilft diese Idee ja irgendwie weiter. Wir hatten damals auch ne Weile gebraucht das herauszufinden. Liebe Grüße, Kevin Sekin.
Hallo Kevin, vielen Dank für deine Antwort. Es wurde alles nochmals geprüft aber leider liegt es nicht daran. ***** as mentioned before the problem (lost POST parameters and customer session) happens only after the application_top.php file is included, before this file is included there is no problem, so that would excluded a problem with the htaccess file / wrong URLs. ***** Ich finde dass ganze Problem wirklich sehr tragisch, vor allem da ich dieses Modul seit 2015 im Einsatz hatte und alle Anpassungen / Updates immer wunderbar geklappt hatten und jetzt scheitert es an irgendwas. Hast du vielleicht noch eine andere Idee? Vielen herzlichen Dank im voraus Grüße
Das ist falsch, da hat der unrecht, das schliesst das nicht aus. Wenn nach einem fehlerhaften Versuch im media Ordner eine neue session-postfix Datei liegt, spräche das sogar genau dafür, und das lässt sich ja leicht checken. Dateidatum beachten.
Nun ... wenn das der Fall ist, dann sollte sich ja recht schnell ermitteln lassen, wodurch diese Weiterleitung initiiert wird. Die application_top.php führt die Application Klasse aus der src/GXMainComponents/Application.inc.php Datei aus. Dort kann es zu mehreren Redirects kommen, jenachdem welche Bedingungen erfüllt sind. Ich würde vorschlagen, die Ausführung bestimmter Teile einmal zu deaktivieren (durch auskommentieren) und dann zu schauen, welcher Abschnitt die Weiterleitung ausführt. Meine heißen Favorieten wären hier: Code: Application::checkRequestUriForCorrectProtocolAndDomain() Application::verifySession() Application::handleCustomRedirect()
Guten Abend an alle vom Gambio Team, danke für eure Unterstützung. Ich hatte alles an Infos weitergeleitet aber leider schafft der Programmierer nicht das Modul zum laufen zu kriegen . Es wird wohl darauf auslaufen, dass ich nach 6 Jahren keine Kreditkarten Zahlungen mehr akzeptieren kann was sich nicht positiv auswirken wird. Als Antwort nach Weiterleitung aller Infos habe ich folgende bekommen: ***** In case there is no decent information available on how maintaining customer session and POST parameters with a payment gateway, there is not much I can do. With the thousands of files and lines of code that this program has been built with it is not something I can do, although I followed already with what they suggested (commenting out parts of code). ***** Das traurige ist, dass ich wie gesagt dass Modul seit Ewigkeiten im Einsatz hatte und es immer funktioniert hatte. Es wurden hin und wieder Anpassungen vorgenommen damit es weiter läuft und jetzt wohl irgendwas anderes ist, so dass es nicht mehr zum laufen gebracht werden kann. Es war bei den Anfangsversionen von GX4 noch lauffähig. Aufgefallen ist mir das Problem erst vor einigen Wochen unter 4.2. Bei der Version, welche im Juli 2020 von GX4 die aktuellste war, hatte es noch funktioniert. Ich habe noch ein anderes Zahlungsmodul (nicht für Kreditkarten). Prinzip ist dass selbe, sprich es wird auf die Seite des Zahlungsproviders weitergeleitet und dann zurück zum Gambio Shop - dieses Modul funktioniert nach wie vor ohne Probleme unter GX 4.2. Aber laut Programmierer läuft dieses Modul im vergleich zum Kreditkarten Modul nicht mit POST im Checkout Prozess sondern anders... Grüße
Ich sehe zum Beispiel kein Feedback, dass das jemand gemacht hat. Entweder müsstest du/ihr Hinweisen die man gibt folgen, oder da muss jemand ran, der sich wirklich auskennt, oder du musst einen anderen Zahlungsanbieter einbinden, für dens was gibt.