Neu PayPal Checkout Rückleitungsurl

[mAze]

Hallo,

Wir bekommen derzeit hin und wieder Anrufe das bei manchen Kunden die PayPal Zahlung nicht funktioniert. Nach dem drücken auf den "Zahlungspflichtig Bestellen" Button kommen diese zwar auf die PayPal Seite zum Bezahlen, allerdings scheint es danach ein Problem mit dem Rücksprung auf die Shopseite zu geben.
Manche Kunden landen dann einfach wieder im Checkout bzw. im Warenkorb der dann Leer ist oder Sie sehen dann einen Kreis der sich dreht. Komischerweise funktionieren auch manche.

Hat das schon mal jemand gehabt ?

Version PayPal Checkout Plugin: 2.0.1
Version JTL Shop: 5.4.1

Welche Automatische Rückleitungsurl muss bie Paypal hinterlegt werden ?



und welche Zahlungsbestätigungsurl ( IPN ) muss hier eingetragen werden ?



Vielen Dank für eure Hilfe
Mathias

 

[bbfdesign]

Hi Mathias,

ich kann mir das gerne einmal anschauen, wenn Du magst. Schreib mir gerne eine PN.

Prüfe mal Deine Einstellungen bezüglich des Mailversandes.

Gruß Björn

 

[mAze]

Hi Mathias,

ich kann mir das gerne einmal anschauen, wenn Du magst. Schreib mir gerne eine PN.

Prüfe mal Deine Einstellungen bezüglich des Mailversandes.

Gruß Björn

Hallo Björn,

Vielen Dank. ich habe dir geschrieben.
Ich erhalte im Log auch folgende Meldung:

[JTL_PAYPAL_COMMERCE] INFORMATION: jtl_paypal_commerce::ioRequest - can not register io handler (CSRF validation failed)

Kann damit jemand etwas anfangen ?

 

[Siluan]

@mAze
Habe bei mehreren Kunden ebenfalls Probleme mit dem neuen PayPal Plugin in der Version 2.0.1 mit Shop 5.5.2.
Sobald der Benutzer auf den "Direkt zu PayPal" Button klickt, öffnet es sich kurz und schließt sich direkt anschließend automatisch.

In den Logs kriegen wir folgendes ausgegeben:

[JTL_PAYPAL_COMMERCE] INFORMATION: jtl_paypal_commerce::ioRequest - can not register io handler (CSRF validation failed)

Es ist sehr verwirrend, dass es bei einigen Shops fehlerfrei funktioniert und bei anderen wiederrum nur teilweise.
Da gibt es auch, soweit ich beobachten konnte, einen Unterschied, ob ein eingeloggter Benutzer oder Gast Benutzer im Shop über PayPal Checkout auschecken möchte.

Ich habe bei allen Shops zum Teil die PayPal Anbindung neu eingerichtet, Webhooks aktualisiert und teilweise sogar das Plugin komplett deinstalliert und wieder neu installiert.
Bisher ohne Erfolg.

Ticket ist seit gestern Abend bei JTL offen, sollte ich selbst oder mit JTL gemeinsam eine Lösung gefunden haben, trage ich das gerne hier nach.

 

[mAze]

@mAze
Habe bei mehreren Kunden ebenfalls Probleme mit dem neuen PayPal Plugin in der Version 2.0.1 mit Shop 5.5.2.
Sobald der Benutzer auf den "Direkt zu PayPal" Button klickt, öffnet es sich kurz und schließt sich direkt anschließend automatisch.

In den Logs kriegen wir folgendes ausgegeben:

[JTL_PAYPAL_COMMERCE] INFORMATION: jtl_paypal_commerce::ioRequest - can not register io handler (CSRF validation failed)

Es ist sehr verwirrend, dass es bei einigen Shops fehlerfrei funktioniert und bei anderen wiederrum nur teilweise.
Da gibt es auch, soweit ich beobachten konnte, einen Unterschied, ob ein eingeloggter Benutzer oder Gast Benutzer im Shop über PayPal Checkout auschecken möchte.

Ich habe bei allen Shops zum Teil die PayPal Anbindung neu eingerichtet, Webhooks aktualisiert und teilweise sogar das Plugin komplett deinstalliert und wieder neu installiert.
Bisher ohne Erfolg.

Ticket ist seit gestern Abend bei JTL offen, sollte ich selbst oder mit JTL gemeinsam eine Lösung gefunden haben, trage ich das gerne hier nach.

Hallo Siluan,

arbeitest du zufällig auch mit einer Redis Datenbank?
Falls ja, hier die Antwort von JTL von meinem Ticket:
Ich konnte allerdings noch nicht Testen ob es nun besser funktioniert.

„
ihr Shop speichert die Session der Kunden scheinbar im Redis- Cache. Leert man den Objektcache, ging auch die Session verloren und man wurde ausgeloggt. Da die Sessions in der Regel immer in Datenbank 0 gespeichert werden, habe ich in den Cache-Einstellungen den Wert auf 1 geändert. Jetzt fliegt der Admin nach dem Löschen des Objektcache nicht mehr aus dem Shop, die Session bleibt aktiv.

Ich vermute selbe Problematik haben auch Ihre Kunden nach der Bezahlung auf der externen Seite, dass die Session im Browser verloren ging. Daher hatte diese dann plötzlich wieder einen leeren Warenkorb.“

Den Fehler hatten wir auch. Dieser kommt nun nicht mehr.
Wir haben bzw. hatten aber das gleiche verhalten wie bei dir.

Liebe Grüße
Mathias

 

[Siluan]

Hallo Siluan,

arbeitest du zufällig auch mit einer Redis Datenbank?
Falls ja, hier die Antwort von JTL von meinem Ticket:
Ich konnte allerdings noch nicht Testen ob es nun besser funktioniert.

„
ihr Shop speichert die Session der Kunden scheinbar im Redis- Cache. Leert man den Objektcache, ging auch die Session verloren und man wurde ausgeloggt. Da die Sessions in der Regel immer in Datenbank 0 gespeichert werden, habe ich in den Cache-Einstellungen den Wert auf 1 geändert. Jetzt fliegt der Admin nach dem Löschen des Objektcache nicht mehr aus dem Shop, die Session bleibt aktiv.

Ich vermute selbe Problematik haben auch Ihre Kunden nach der Bezahlung auf der externen Seite, dass die Session im Browser verloren ging. Daher hatte diese dann plötzlich wieder einen leeren Warenkorb.“

Den Fehler hatten wir auch. Dieser kommt nun nicht mehr.
Wir haben bzw. hatten aber das gleiche verhalten wie bei dir.

Liebe Grüße
Mathias

Hallo Mathias,

tatsächlich unterschiedlich.
Bei einigen Kunden verwenden wir Redis, bei anderen wiederrum APC.
Der Fehler tritt aber bei beiden Caching Methoden auf.

Bei den Kunden wo Redis im Einsatz ist, haben wir 2 Redis Datenbanken pro Shop.
Datenbank 0 wird für die Sessions verwendet und Datenbank 1 für den Object-Cache.
Den Fehler den du quasi hattest, haben wir in unseren Fällen nicht, da die Konfiguration bereits korrekt ist.

Beste Grüße
Siluan

 

[mAze]

kurzes Update dazu: heute morgen ist der Fehler "[JTL_PAYPAL_COMMERCE] INFORMATION: jtl_paypal_commerce::ioRequest - can not register io handler (CSRF validation failed)" bei mir auch wieder aufgetreten.

Mir fällt dieser Fehler komischerweise auch erst auf mit dem neuen Update des Plugins auf 2.0.0 bzw. 2.0.1

Ich hatte zudem heute morgen selbst mal eine Bestellung ausgelöst als unregistrierter Kunde, diese hatte zwar funktioniert, ich gehe aber trotzdem davon aus das das Problem damit noch nicht behoben ist.

LG
Mathias

 

[Siluan]

kurzes Update dazu: heute morgen ist der Fehler "[JTL_PAYPAL_COMMERCE] INFORMATION: jtl_paypal_commerce::ioRequest - can not register io handler (CSRF validation failed)" bei mir auch wieder aufgetreten.

Mir fällt dieser Fehler komischerweise auch erst auf mit dem neuen Update des Plugins auf 2.0.0 bzw. 2.0.1

Ich hatte zudem heute morgen selbst mal eine Bestellung ausgelöst als unregistrierter Kunde, diese hatte zwar funktioniert, ich gehe aber trotzdem davon aus das das Problem damit noch nicht behoben ist.

LG
Mathias

Ebenfalls ein Update seitens JTL, wie folgt:

Zu Paypal:
Folgende Anpassung wurde testweise eingebaut, eine Versionierung des Javascript, damit die Browser der Kunden nichts aus dem Cache ziehen:
Dazu wurde hier https://gitlab.com/jtl-software/jtl...rontend/PayPalFrontend.php?ref_type=heads#L82 und hier https://gitlab.com/jtl-software/jtl...ontend/PayPalFrontend.php?ref_type=heads#L478 das
'init.js'

durch ein

'init.js?v=1.1.0'

ersetzt.

Jetzt muss beobachtet werden, ob es weiterhin Probleme & Fehlermeldungen gibt, oder ob es damit vielleicht schon behoben ist. Da euer Shop gut besucht ist, sollte sich hier schnell eine Tendenz zeigen. Bitte die Zugänge nicht abschalten, ich behalte das nebenbei ebenfalls mit im Auge.

Noch eine Vermutung zu der Redis Thematik, meinerseits.
Bei den Shops wo man Redis nicht nur für den Object-Cache sondern auch für die Sessions verwendet, wird es daran liegen, das der Redis-Cache zu unterschiedlichen Zeiten natürlich bedingt voll läuft.
Sobald dies der Fall ist, hat man die Thematik das es bei einigen Usern das PayPal Checkout Plugin funktioniert und bei anderen wiederrum nicht.
Ich verwende für die "MaxMemory Policy" den Wert "allkeys-lfu".
Dies löscht die am wenigsten genutzten Einträge.
Und das wird auch vermutlich das Problem sein.

Ich hab jetzt bei allen Kundenshops wo wir Redis für die Sessions verwenden auf die Standard Dateibasierte Session-Verwaltung geändert und nur noch den reinen Object-Cache auf Redis beibelassen.

Beste Grüße
Siluan

 

[mAze]

Ebenfalls ein Update seitens JTL, wie folgt:



Noch eine Vermutung zu der Redis Thematik, meinerseits.
Bei den Shops wo man Redis nicht nur für den Object- Cache sondern auch für die Sessions verwendet, wird es daran liegen, das der Redis-Cache zu unterschiedlichen Zeiten natürlich bedingt voll läuft.
Sobald dies der Fall ist, hat man die Thematik das es bei einigen Usern das PayPal Checkout Plugin funktioniert und bei anderen wiederrum nicht.
Ich verwende für die "MaxMemory Policy" den Wert "allkeys-lfu".
Dies löscht die am wenigsten genutzten Einträge.
Und das wird auch vermutlich das Problem sein.

Ich hab jetzt bei allen Kundenshops wo wir Redis für die Sessions verwenden auf die Standard Dateibasierte Session-Verwaltung geändert und nur noch den reinen Object-Cache auf Redis beibelassen.

Beste Grüße
Siluan

Hallo Siluan,

Vielen Dank für die Info.
Die Anpassung wurde bei uns auch durchgeführt.

Zu deiner Vermutung: Wir sind bei TimmeHosting und nutzen ebenfalls die die "MaxMemory Policy" den Wert "allkeys-lfu".
bei "Max. Anzahl Datenbanken" steht bei uns 2, da weiß ich nicht ob das passt ? und bei "Max. Größe der Datenbank" 3072mb von Max. 7807MB
Der "Persistenzmodus" ist aus

evtl. kann JTL was dazu sagen zu den Redis Einstellungen.

LG
Mathias

 

[Siluan]

Hallo Siluan,

Vielen Dank für die Info.
Die Anpassung wurde bei uns auch durchgeführt.

Zu deiner Vermutung: Wir sind bei TimmeHosting und nutzen ebenfalls die die "MaxMemory Policy" den Wert "allkeys-lfu".
bei "Max. Anzahl Datenbanken" steht bei uns 2, da weiß ich nicht ob das passt ? und bei "Max. Größe der Datenbank" 3072mb von Max. 7807MB

evtl. kann JTL was dazu sagen zu den Redis Einstellungen.

LG
Mathias

Ebenfalls Timmehosting.
"Max. Anzahl Datenbanken" auf 2 ist korrekt, sofern man auch die Sessions über Redis laufen lässt.
Falls nicht, kannst du es trotzdem bei 2 belassen, da Redis nicht die Aufteilung des RAMs statisch auf Datenbanken aufteilt.

Hast du in den php.ini Einstellungen ebenfalls den Session-Handler drin?
Der lautet im Standard wie folgt:
session.save_handler = redis session.save_path = "unix://{REDIS_SOCKET}?database=0&auth={REDIS_PASSWORD}" session.cache_expire = 1440

Den o.g. Session-Handler (session.save_handler und session.save_path) hab ich bei meinen Kunden vorerst raus geschmissen, da dies auch bei manchen Kunden in Verbindung mit dem Mollie Plugin bereits Probleme bereitet hat.
So das die Sessions wieder Dateibasierend, klassisch auf der Festplatte liegen.

 

[mAze]

Ebenfalls Timmehosting.
"Max. Anzahl Datenbanken" auf 2 ist korrekt, sofern man auch die Sessions über Redis laufen lässt.
Falls nicht, kannst du es trotzdem bei 2 belassen, da Redis nicht die Aufteilung des RAMs statisch auf Datenbanken aufteilt.

Hast du in den php.ini Einstellungen ebenfalls den Session-Handler drin?
Der lautet im Standard wie folgt:
session.save_handler = redis session.save_path = "unix://{REDIS_SOCKET}?database=0&auth={REDIS_PASSWORD}" session.cache_expire = 1440

Den o.g. Session-Handler (session.save_handler und session.save_path) hab ich bei meinen Kunden vorerst raus geschmissen, da dies auch bei manchen Kunden in Verbindung mit dem Mollie Plugin bereits Probleme bereitet hat.
So das die Sessions wieder Dateibasierend, klassisch auf der Festplatte liegen.

irgendwie stehe ich gerade auf dem Schlauch. Du meinst die config.JTL- Shop.ini.php unter /includes ?

 

[Siluan]

irgendwie stehe ich gerade auf dem Schlauch. Du meinst die config.JTL-Shop.ini.php unter /includes ?

Nein.
im ISPConfig bei Timmehosting unter "Webseiten" die gewünschte Domain auswählen.
Dann hast du mehrere Tabs, siehe Screenshot:


Hier "Optionen" auswählen.
Wenn du etwas dann weiter runter scrollst, sieht du das Feld mit dem Label "Individuelle php.ini-Einstellungen".

Ist auch ausführlicher in der Timmehosting Anleitung beschrieben.
Ich habe aber wie gesagt die Sessions wieder von Redis raus genommen und auf Standard belassen.
Nur der Object- Cache läuft aktuell noch über Redis.
Siehe: https://timmehosting.de/jtl-shop-4-und-5-mit-redis-verbinden

 

[mAze]

ah ok das meinst du
Bei uns steht es noch drin:

session.save_handler = redis
session save_path = "unix://{REDIS_SOCKET}?database=0&auth={REDIS_PASSWORD}"

allerdings nicht das --> session.cache_expire = 1440

Bist du der Meinung das dieser Eintrag auch die Ursache sein könnte bei unseren Problem mit PayPal?

 

[Harald Weingaertner]

Hi und eine kurze Zwischenfrage:.

Wo ich das hier lese, fällt mir auch auf, dass seit Update auf Paypal 2.0.1 auch noch keine Bestellung über Paypal gekommen ist. Das ist ungewöhnlich.

Die Frage: Wo findet man denn das Logfile, in dem ihr diese Felermeldungen ([JTL_PAYPAL_COMMERCE] INFORMATION: jtl_paypal_commerce::ioRequest - can not register io handler (CSRF validation failed)) seht? Im Shop nicht, oder?

Danke und Grüße, Harald

 

[mAze]

Hi und eine kurze Zwischenfrage:.

Wo ich das hier lese, fällt mir auch auf, dass seit Update auf Paypal 2.0.1 auch noch keine Bestellung über Paypal gekommen ist. Das ist ungewöhnlich.

Die Frage: Wo findet man denn das Logfile, in dem ihr diese Felermeldungen ([JTL_PAYPAL_COMMERCE] INFORMATION: jtl_paypal_commerce::ioRequest - can not register io handler (CSRF validation failed)) seht? Im Shop nicht, oder?

Danke und Grüße, Harald

Hallo Harald,

Doch, du findest den Fehler im Shop Backend unter Administration > Fehlerbehebung > Logbuch

so wie ich das hier sehe ist es wirklich ein Plugin Fehler seit dem Update auf 2.0.0
Hoffentlich reagiert JTL schnell.

 

[Siluan]

ah ok das meinst du
Bei uns steht es noch drin:

session.save_handler = redis
session save_path = "unix://{REDIS_SOCKET}?database=0&auth={REDIS_PASSWORD}"

allerdings nicht das --> session.cache_expire = 1440

Bist du der Meinung das dieser Eintrag auch die Ursache sein könnte bei unseren Problem mit PayPal?

Ich würde sagen indirekt.
Die session.cache_expire dient für die Dauer der Session.
Siehe Timmehosting Ausschnitt dazu:


Dadurch das man es von dem Standard (20 Minuten) auf 1 Tag erhöht, läuft der Cache über den Tag verteilt voll.
Ab dem Punkt, bin ich zu wenig auf Shop Core Ebene unterwegs, das ich wissen kann, was genau passiert sobald der Cache an der Stelle voll läuft.
Nach der "MaxMemory Policy" Einstellung müsste es technisch bedeuten das gewisse Caches aus dem Cache Index genommen werden müssten.
Evtl. kann ein Backend-Entwickler oder jemand aus dem JTL-Team genaueres dazu sagen.

 

[Harald Weingaertner]

Hallo Harald,

Doch, du findest den Fehler im Shop Backend unter Administration > Fehlerbehebung > Logbuch

so wie ich das hier sehe ist es wirklich ein Plugin Fehler seit dem Update auf 2.0.0
Hoffentlich reagiert JTL schnell.

Danke mAze,

und dort dann unter der Lasche "Plugin-Status Updates"?

Die Lasche "Log" ist komplett leer und bei "Plugin-Status Updates" -> "Paypal" steht nur, wann es deaktiviert und wieder aktiviert wurde. Loglevel "Fehler".

Mich macht dieser Thread auch gerade nervös, denn 2 ganze Tage ohne Paypal Bestellungen ist eigentlich unmöglich.

 

[Siluan]

Hi und eine kurze Zwischenfrage:.

Wo ich das hier lese, fällt mir auch auf, dass seit Update auf Paypal 2.0.1 auch noch keine Bestellung über Paypal gekommen ist. Das ist ungewöhnlich.

Die Frage: Wo findet man denn das Logfile, in dem ihr diese Felermeldungen ([JTL_PAYPAL_COMMERCE] INFORMATION: jtl_paypal_commerce::ioRequest - can not register io handler (CSRF validation failed)) seht? Im Shop nicht, oder?

Danke und Grüße, Harald

Bei einigen Shops muss man nachdem Update, im PayPal Checkout Plugin die Verbindung zum PayPal Konto trennen und neu verbinden.
Am besten noch vorsichtshalber die Webhooks im Anschluss neu triggern lassen.

 

[mAze]

Ich würde sagen indirekt.
Die session.cache_expire dient für die Dauer der Session.
Siehe Timmehosting Ausschnitt dazu:
Den Anhang 123024 betrachten

Dadurch das man es von dem Standard (20 Minuten) auf 1 Tag erhöht, läuft der Cache über den Tag verteilt voll.
Ab dem Punkt, bin ich zu wenig auf Shop Core Ebene unterwegs, das ich wissen kann, was genau passiert sobald der Cache an der Stelle voll läuft.
Nach der "MaxMemory Policy" Einstellung müsste es technisch bedeuten das gewisse Caches aus dem Cache Index genommen werden müssten.
Evtl. kann ein Backend-Entwickler oder jemand aus dem JTL-Team genaueres dazu sagen.

ich kann mir allerdings auch nicht vorstellen da es am Redis Cache liegt. Hier mal eine aktuelle Speicherabfrage aus Timme des Redis

# Memory
used_memory:397118712
used_memory_human:378.72M
used_memory_rss:456982528
used_memory_rss_human:435.81M
used_memory_peak:2842151416
used_memory_peak_human:2.65G
used_memory_peak_perc:13.97%
used_memory_overhead:2906888
used_memory_startup:870064
used_memory_dataset:394211824
used_memory_dataset_perc:99.49%
allocator_allocated:398316440
allocator_active:461459456
allocator_resident:478633984
total_system_memory:16373207040
total_system_memory_human:15.25G
used_memory_lua:31744
used_memory_vm_eval:31744
used_memory_lua_human:31.00K
used_memory_scripts_eval:0
number_of_cached_scripts:0
number_of_functions:0
number_of_libraries:0
used_memory_vm_functions:32768
used_memory_vm_total:64512
used_memory_vm_total_human:63.00K
used_memory_functions:200
used_memory_scripts:200
used_memory_scripts_human:200B
maxmemory:3072000000
maxmemory_human:2.86G
maxmemory_policy:allkeys-lfu
allocator_frag_ratio:1.16
allocator_frag_bytes:63143016
allocator_rss_ratio:1.04
allocator_rss_bytes:17174528
rss_overhead_ratio:0.95
rss_overhead_bytes:-21651456
mem_fragmentation_ratio:1.15
mem_fragmentation_bytes:59902120
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_total_replication_buffers:0
mem_clients_slaves:0
mem_clients_normal:0
mem_cluster_links:0
mem_aof_buffer:0
mem_allocator:jemalloc-5.3.0
active_defrag_running:0
lazyfree_pending_objects:0
lazyfreed_objects:1756

bei JTL im Backend sieht es so aus:





Passt also fast überein. Da ist aktuell viel Luft. Konnte auch nie beobachten das das mal an Sie 3GB ran gekommen ist

 

[Siluan]

ich kann mir allerdings auch nicht vorstellen da es am Redis Cache liegt. Hier mal eine aktuelle Speicherabfrage aus Timme des Redis

# Memory
used_memory:397118712
used_memory_human:378.72M
used_memory_rss:456982528
used_memory_rss_human:435.81M
used_memory_peak:2842151416
used_memory_peak_human:2.65G
used_memory_peak_perc:13.97%
used_memory_overhead:2906888
used_memory_startup:870064
used_memory_dataset:394211824
used_memory_dataset_perc:99.49%
allocator_allocated:398316440
allocator_active:461459456
allocator_resident:478633984
total_system_memory:16373207040
total_system_memory_human:15.25G
used_memory_lua:31744
used_memory_vm_eval:31744
used_memory_lua_human:31.00K
used_memory_scripts_eval:0
number_of_cached_scripts:0
number_of_functions:0
number_of_libraries:0
used_memory_vm_functions:32768
used_memory_vm_total:64512
used_memory_vm_total_human:63.00K
used_memory_functions:200
used_memory_scripts:200
used_memory_scripts_human:200B
maxmemory:3072000000
maxmemory_human:2.86G
maxmemory_policy:allkeys-lfu
allocator_frag_ratio:1.16
allocator_frag_bytes:63143016
allocator_rss_ratio:1.04
allocator_rss_bytes:17174528
rss_overhead_ratio:0.95
rss_overhead_bytes:-21651456
mem_fragmentation_ratio:1.15
mem_fragmentation_bytes:59902120
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_total_replication_buffers:0
mem_clients_slaves:0
mem_clients_normal:0
mem_cluster_links:0
mem_aof_buffer:0
mem_allocator:jemalloc-5.3.0
active_defrag_running:0
lazyfree_pending_objects:0
lazyfreed_objects:1756

bei JTL im Backend sieht es so aus:



Den Anhang 123030 betrachten

Passt also fast überein. Da ist aktuell viel Luft. Konnte auch nie beobachten das das mal an Sie 3GB ran gekommen ist

Bei dir läuft die Session wahrscheinlich nicht voll, da die Session Laufzeit auf 20 Minuten ist.
Wir haben 4GB und bei einem anderen Shop 8GB Redis Speicher und die sind trotzdem voll gelaufen.
Seit der Umstellung des Session Handlers von Redis auf Standard (File), haben wir das Problem vorerst nicht mehr.