2016-07-13 15 views
2

Ich habe einen PayPal IPN Handler, der seit über 5 Jahren (mit verschiedenen Updates im Laufe der Zeit) gearbeitet hat. Gestern hörte ich plötzlich auf, die normale '&' und '=' getrennte Datenfolge zu empfangen und fing an, 6 Müll-Nicht-ASCII-Zeichen zu erhalten.PayPal IPN plötzlich Müll

Wenn ich log die Daten von PayPal direkt in kommenden, bevor eine Bestätigung, Parsing, Handling, was auch immer, ich normalerweise

[2016.07.13 04.46 UTC] handling_amount Rohdaten = 0,00 & Rabatt = 0.00 & insurance_amount = 0.00 & payer_id = bla bla bla usw.

Jetzt bin ich gerade dies immer

[2016.07.13 04.37 UTC] Rohdaten xæÕ-

Es ist nie die gleiche Menge von Zeichen, aber immer Müll (und nur etwa 6 Zeichen).

Ich habe die Codierung in meinem PayPal-Konto überprüft und auf UTF-8 eingestellt. Hat nicht geholfen. Ich habe den PayPal IPN Simulator mit dem exakt gleichen Code verwendet (Adresse in Sandbox geändert) und es funktioniert einwandfrei. Ich habe versucht, drei separate IPNs aus dem IPN-Verlauf von PayPal erneut zu senden, darunter 1, der nicht ernsthaft fehlgeschlagen ist. Keine von ihnen funktioniert, alle ergeben die gleichen Abfalldaten. Ich habe versucht, die Eingabe von PayPal direkt als $ _POST und file_get_contents ('php: // input') zu behandeln. Es gibt keinen Unterschied; Alles funktioniert im Simulator und es ist nur Müll von Live.

Hier ist mein Listener-Code. Es ist ungefähr das gleiche wie die Beispiele, die Sie woanders online sehen.

<?php 
error_reporting(E_ALL^E_NOTICE); 

define("LOG_FILE", "./ipn.log"); 

$raw_post_data = file_get_contents('php://input'); 
error_log(date('[Y-m-d H:i e] '). "Raw data " . $raw_post_data . PHP_EOL, 3, LOG_FILE); 
$raw_post_array = explode('&', $raw_post_data); 
$myPost = array(); 
foreach ($raw_post_array as $keyval) 
{ 
    $keyval = explode ('=', $keyval); 
    if (count($keyval) == 2) 
     $myPost[$keyval[0]] = urldecode($keyval[1]); 
} 
// Read the post from PayPal and add 'cmd' 
$req = 'cmd=_notify-validate'; 
foreach ($myPost as $key => $value) 
{ 
    if($get_magic_quotes_exists == true && get_magic_quotes_gpc() == 1) { 
     $value = urlencode(stripslashes($value)); 
    } else { 
     $value = urlencode($value); 
    } 
    $req .= "&$key=$value"; 
} 

Dies zeigt nur die Daten empfangen und analysieren. Beachten Sie in Zeile 7 den Aufruf error_log. Hier kommen die obigen Zitate her. Normalerweise sind die Daten in Ordnung (und mit Sandbox ist es in Ordnung). Aber plötzlich sind die Protokolldaten für die Live-Site Müll. Das Problem besteht nicht darin, eine Verbindung zu PayPal herzustellen oder "verifiziert" oder "ungültig" zurück zu bekommen, da keine Daten zum Verifizieren oder Parsen vorhanden sind.

Hat das jemand schon einmal erlebt? Es scheint sicherlich ein Codierungsproblem zu sein, aber ich habe die Codierung auf UTF-8 eingestellt. Und es ist nicht so, als wäre es ein Teilcodierungsproblem, bei dem einige der Daten schlecht sind. Das Ganze ist schlecht. Danke!

+0

Ich frage mich, ob PayPal jetzt Tls12 zwingt. – David

+0

Ich habe festgestellt, dass die ungültigen Daten nur auftreten, wenn ich ein IPN * erneut sende, indem ich mich bei PayPal anmelde, die IPN-Verlaufsseite besuche und ein vorheriges IPN erneut sende. IPNs, die aus der Sandbox gesendet werden, und alle * ursprünglichen * IPNs werden korrekt gesendet. Jedes einzelne * Resend *, das ich versuche, führt zu ungültigen Daten. Es scheint mir ziemlich offensichtlich, dass das Problem mit PayPal ist. Ob es nur mein Konto ist oder nicht, ich weiß es nicht. – avariant

Antwort

0

Ich habe den technischen Support von PayPal kontaktiert, aber dieses Problem wurde nie gelöst. Ich bin mir sicher, dass es an diesem Punkt ein Problem an ihrem Ende ist, da das einzige, was fehlschlägt, ist IPN erneut zu senden. Es war nützlich, das zu haben, aber ich kann ohne es überleben.