connecting to google talk through a bosh server using php - xmpp

I am creating my own php bosh connector so I
can attach() to strophe. Here is my exchange and I'm getting a Bad
Authentication error (which is a google specific error). The exchanges seem to be exactly the same as within
strophe when I connect with strophe successfully, do you know what is the problem?
<body rid='5559198240000' xmlns='http://jabber.org/protocol/httpbind'
to='babson.edu' xml:lang='en' wait='60' hold='1' window='5'
content='text/xml; charset=utf-8' ver='1.6' xmpp:version='1.0'
xmlns:xmpp='urn:xmpp:xbosh'/>
string(500) "<body xmlns='http://jabber.org/protocol/httpbind'
inactivity='60' secure='true' authid='BECF5BCD50577C01' content='text/xml;
charset=utf-8' window='5' polling='15'
sid='4ad843a8e15c79e34976783c96785bd5' requests='2'
wait='60'><stream:features xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:client'><mechanisms
xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>PLAIN</mechanism><mecha
nism>X-GOOGLE-TOKEN</mechanism><mechanism>X-OAUTH2</mechanism></mechanisms>
</stream:features></body>"
<body rid='5559198240001' xmlns='http://jabber.org/protocol/httpbind'
sid='4ad843a8e15c79e34976783c96785bd5'><auth
xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='PLAIN'>same_base_64_translated_string_as_in_strophe=</auth></bod
y>
string(24) "Error=BadAuthentication
I've checked and the base_64 SASL encoded string is exactly the same as in my strophe logs where I connect successfully. But my php program sending the same exact xml gets this BadAuthentication error.

I was using the wrong curl headers:
this is the correct way to use curl to speak with BOSH for anybody else that finds this post:
$ch = curl_init($bosh_url);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $xmlpost);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
$header = array('Accept-Encoding: gzip, deflate','Content-Type: text/xml; charset=utf-8');
curl_setopt($ch, CURLOPT_HTTPHEADER, $header );
curl_setopt($ch, CURLOPT_VERBOSE, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$response = curl_exec($ch);
var_dump($response);

Related

Perl SOAP::Lite call fails

I am trying to call a Soap Webservice.I have to pass the name of a Code table (for eg STATE_CODES) and it returns key value pair like NY - New york, DE-Delaware etc.
#!/usr/local/bin/perl
use strict;
use warnings;
use Data::Dumper qw<Dumper>;
#use SOAP::Lite trace=>'all';
use SOAP::Lite +trace =>'debug';
#use SOAP::Lite;
$ENV{PERL_LWP_SSL_VERIFY_HOSTNAME}=0;
use Data::Dumper; $Data::Dumper::Terse = 1; $Data::Dumper::Indent = 1;
#my $wsdl = 'https://dev1:2001/ACTS?wsdl';
my $endpoint = 'https://qa1:2001/ACTS';
my $wsdl = 'HTTPS://QA1:2001/ACTS?wsdl';
my $method_name = 'impl:getCodes';
my $uri = 'http://impl.webservice.acts.ito.aoc.nj';
my $ns = 'http://impl.webservice.acts.ito.aoc.nj';
my $client = SOAP::Lite->new(
proxy=>$endpoint,
service=>$wsdl,
readable=>1
);
$client->outputxml(1);
$client->envprefix('soapenv');
$client->ns($uri,'impl');
$client->outputxml('true');
my #param;
push #param, SOAP::Data->name("codeTable"=>'STATE_CODES');
my $soapResp = $client->call($method_name,#param);
print $soapResp;
print "\n";
Output:
[root#np1 ~]# perl /test/soaptest6.pl
SOAP::Transport::HTTP::Client::send_receive: POST https://qa1:2001/ACTS HTTP/1.1
Accept: text/xml
Accept: multipart/*
Accept: application/soap
Content-Length: 580
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://impl.webservice.acts.ito.aoc.nj#getCodes"
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:impl="http://impl.webservice.acts.ito.aoc.nj"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<impl:getCodes>
<codeTable xsi:type="xsd:string">STATE_CODES</codeTable>
</impl:getCodes>
</soapenv:Body>
</soapenv:Envelope>
SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 500 Error
Connection: close
Content-Type: text/xml; charset=utf-8
Client-Date: Sat, 24 Oct 2020 02:46:04 GMT
Client-Peer: 192.168.248.33:2001
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /CN=qa1
Client-SSL-Cert-Subject: /CN=qa1
Client-SSL-Cipher: ECDHE-RSA-AES256-GCM-SHA384
Client-SSL-Socket-Class: IO::Socket::SSL
Client-SSL-Warning: Peer certificate not verified
X-Backside-Transport: FAIL FAIL
<?xml version='1.0' ?>
<env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
<env:Body>
<env:Fault>
<faultcode>env:Client</faultcode>
<faultstring>Internal Error</faultstring>
</env:Fault>
</env:Body>
</env:Envelope>
<?xml version='1.0' ?>
<env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
<env:Body>
<env:Fault>
<faultcode>env:Client</faultcode>
<faultstring>Internal Error</faultstring>
</env:Fault>
</env:Body>
</env:Envelope>
The soap request kind of looks good, but it gives error. I pasted the soap request into SOAPUI and it gave error. But as soon as i removed the line before the xml tag. in the soapAction, the request worked.
Why is my soap request resulting in failure. is it because of some certificate issue. i believe i have asked the code to skip certificate validation and Client-SSL-Warning: Peer certificate not verified in output above is just a warning and can be ignored.

HTTP 401 Basic Authentication error accessing Magento 2 Rest API

I am attempting to use the Rest API in Magento 2. I have a piece of PHP that uses cURL to first get an admin token for my Magento user, then use the token to return a piece of Magento data (in this example a list of product types). The first part returns a token with no problems, but the second part comes back with an HTTP 401 Basic Authentication error.
My code is:
<?php
// Get handle for token retrieval
$userData = array("username" => "user", "password" => "password!");
$ch = curl_init("https://my.magento/rest/V1/integration/admin/token/");
// Set options
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST");
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($userData));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HTTPHEADER, array("Content-Type: application/json", "Content-Length: " . strlen(json_encode($userData))));
curl_setopt($ch, CURLOPT_VERBOSE, true);
$verbose = fopen('/tmp/curl.log', 'w+');
curl_setopt($ch, CURLOPT_STDERR, $verbose);
// Get token
$token = curl_exec($ch);
echo "Token returned: " . $token . "<BR><BR>";
// Display log
rewind($verbose);
$verboseLog = stream_get_contents($verbose);
echo "Verbose information 1:\n<pre>", htmlspecialchars($verboseLog), "</pre>\n";
echo "About to get product<BR>";
// Get handle for product types
$ch = curl_init("https://my.magento/rest/V1/products/types/");
// Set options
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "GET");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HTTPHEADER, array("Content-Type: application/json", "Authorization: Bearer " . json_decode($token)));
curl_setopt($ch, CURLOPT_VERBOSE, true);
$verbose = fopen('/tmp/curl.log', 'w+');
curl_setopt($ch, CURLOPT_STDERR, $verbose);
// Get types
$result = curl_exec($ch);
echo "Result: " . $result . "<BR>";
// Display log
rewind($verbose);
$verboseLog = stream_get_contents($verbose);
echo "<BR>Verbose information 2:\n<pre>", htmlspecialchars($verboseLog), "</pre>\n";
?>
And the browser output is:
Tokenreturned: "t8iskt68xlo5frf9hhtc1lk8wmqzbzx8"
Verbose information 1:
* About to connect() to my.magento port 443 (#2)
* Trying 104.25.128.20...
* Connected to mymagento (nn.nn.nn.nn) port 443 (#2)
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=ssl379212.cloudflaressl.com,OU=PositiveSSL Multi-Domain,OU=Domain Control Validated
* start date: Oct 26 00:00:00 2018 GMT
* expire date: May 04 23:59:59 2019 GMT
* common name: ssl379212.cloudflaressl.com
* issuer: CN=COMODO ECC Domain Validation Secure Server CA 2,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
> POST /rest/V1/integration/admin/token/ HTTP/1.1
Host: sand2.firetoys.co.uk
Accept: */*
Content-Type: application/json
Content-Length: 48
* upload completely sent off: 48 out of 48 bytes
< HTTP/1.1 200 OK
< Date: Wed, 31 Oct 2018 12:50:01 GMT
< Content-Type: application/json; charset=utf-8
< Content-Length: 34
< Connection: keep-alive
< Set-Cookie: __cfduid=d69af7d1f0a1205231a8867c1f45875621540990201; expires=Thu, 31-Oct-19 12:50:01 GMT; path=/; domain=.my.magento; HttpOnly
< X-Frame-Options: SAMEORIGIN
< X-UA-Compatible: IE=edge
< Pragma: no-cache
< Expires: -1
< Cache-Control: no-store, no-cache, must-revalidate, max-age=0
< Accept-Ranges: bytes
< Set-Cookie: PHPSESSID=9p378rsfito8gfocnrufucssh6; expires=Wed, 31-Oct-2018 13:50:01 GMT; Max-Age=3600; path=/; domain=sand2.firetoys.co.uk; secure; HttpOnly
< Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< Server: cloudflare
< CF-RAY: 47263eb629ea0ce9-LHR
<
* Connection #2 to host my.magento left intact
About to get product
Result:
Verbose information 2:
* About to connect() to my.magento port 443 (#3)
* Trying nn.nn.nn.nn...
* Connected to my.magento (nn.nn.nn.nn) port 443 (#3)
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=ssl379212.cloudflaressl.com,OU=PositiveSSL Multi-Domain,OU=Domain Control Validated
* start date: Oct 26 00:00:00 2018 GMT
* expire date: May 04 23:59:59 2019 GMT
* common name: ssl379212.cloudflaressl.com
* issuer: CN=COMODO ECC Domain Validation Secure Server CA 2,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
> GET /rest/V1/products/types/ HTTP/1.1
Host: sand2.firetoys.co.uk
Accept: */*
Content-Type: application/json
Authorization: Bearer t8iskt68xlo5frf9hhtc1lk8wmqzbzx8
< HTTP/1.1 401 Unauthorized
< Date: Wed, 31 Oct 2018 12:50:01 GMT
< Content-Length: 0
< Connection: keep-alive
< Set-Cookie: __cfduid=d38c9e4bc3019d9ac55c7f68f5c5ca1161540990201; expires=Thu, 31-Oct-19 12:50:01 GMT; path=/; domain=.my.magento; HttpOnly
< X-Varnish: 7995397
< WWW-Authenticate: Basic
< Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< Server: cloudflare
< CF-RAY: 47263eb70f5b3512-LHR
<
* Connection #3 to host my.magento left intact
When I try just browsing directly to https://my.magento/rest/V1/products/types/ I get a Magento error back saying I am not authorised for the Products resource, which I would expect as I am sending no token or login credentials, but at least it is getting through to Magento.
Any ideas??
I should add that the server is set for Basic authentication, and if I replace the Bearer auth with the necessary Basic auth in the header for the GET, it returns the Magento message about not having access to the resource, which is fair enough. So I guess there are two questions:
How can I get past the basic authentication and still include the bearer authentication in my GET request, given that you can't put two authentications into the header?
Why does the initial POST to get the token work without any basic auth??
"How can I get past the basic authentication and still include the bearer authentication in my GET request, given that you can't put two authentications into the header?"
Disable auth for /index.php/rest location (in webserver)
"Why does the initial POST to get the token work without any basic auth??"
If the POST location is protected then you should get a 401 response.
Did you put the username and password on url on post request? http://user:pass#my.magento/rest/V1/
By the way, putting user:pass#my.magento into URL, will be translated into Authorization: User .
But you also set Authorization: Bearer t8iskt68xlo5frf9hhtc1lk8wmqzbzx8 which will overwrite the http authentification Authorization.

Commands need to be run with admin privilege Ejabberd Rest Api?

I am configuring Ejabberd Rest API on ejabberd 16.09. TO configure it i am just following ejabberd Document (https://docs.ejabberd.im/developer/ejabberd-api/simple-configuration/). So when i am going to hit http://localhost:5280/api/change_password url from postman with body:
{
"user": "123",
"host": "TT_CPU_076",
"newpass": "blank"
}
and header: Content-Type: application/json. I am getting an error like:
{
"status": "error",
"code": 31,
"message": "Command need to be run with admin priviledge."
}
my ejabberd.yml file configuration like:
port: 5280
module: ejabberd_http
ip: "127.0.0.1"
request_handlers:
"/websocket": ejabberd_http_ws
"/api": mod_http_api
## "/pub/archive": mod_http_fileserver
web_admin: true
http_bind: true
## register: true
captcha: false
api_permissions:
"API used from localhost allows all calls":
- who:
- ip: "127.0.0.1/8"
- what:
- "*"
- "!stop"
- "!start"
Any solution to achieve Rest Api configuration with ejabberd will be appreciate.
I cannot reproduce that problem with a recent ejabberd 18.04. I set in ejabberd.yml:
hosts:
- "localhost"
- "TT_CPU_076"
api_permissions:
"public commands":
who:
- ip: "127.0.0.1/8"
what:
- "*"
- "status"
- "connected_users_number"
Then I register that account:
$ ejabberdctl register 123 TT_CPU_076 pass11
User 123#TT_CPU_076 successfully registered
I write a simple API client:
<?php
$url='localhost:5280/api/change_password/';
$info=array("user"=>"123",
"host"=>"TT_CPU_076",
"newpass"=>"mypass22"
);
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($info));
$output=curl_exec($ch);
curl_close($ch);
print_r($output);
?>
Then I execute it:
$ php test.php
0
This is logged in ejabberd:
11:39:18.646 [info] API call change_password
[{<<"user">>,<<"123">>},
{<<"host">>,<<"TT_CPU_076">>},
{<<"newpass">>,<<"mypass22">>}]
from ::ffff:127.0.0.1:46778
And finally, I check the database, and the password has changed

Authentication failed. API credentials are incorrect

I've been trying to create a Paypal adaptive payments API call to the sandbox all day now without success. I've read dozends of tutorials, SE threads etc but nothing I tried worked. I keep getting the "Authentication failed. API credentials are incorrect." error message.
The following is the code I'm using:
$baseurl = 'https://svcs.sandbox.paypal.com/AdaptivePayments/Pay';
define('PAYPAL_API_USER', '<snip>');
define('PAYPAL_API_PWD', '<snip>');
define('PAYPAL_API_SIGNATURE', '<snip>');
define('PAYPAL_API_APPLICATION_ID', 'APP-80W284485P519543T');
$returnurl = "<snip>";
$cancelurl = "<snip>";
$data = array(
"actionType" => "PAY",
"currencyCode" => "USD",
"receiverList" => array(
"receiver" => array(
array(
"amount" => "1.00",
"email" => "<snip>"
),
)
),
"returnUrl" => $returnurl,
"cancelUrl" => $cancelurl,
"requestEnvelope" => array(
"errorLangauge" => "en_US",
"detailLevel" => "ReturnAll",
)
);
$headers = array(
"X-PAYPAL-SECURITY-USERID: ".PAYPAL_API_USER,
"X-PAYPAL-SECURITY-PASSWORD: ".PAYPAL_API_PWD,
"X-PAYPAL-SECURITY-SIGNATURE: ".PAYPAL_API_SIGNATURE,
"X-PAYPAL-SECURITY-REQUEST-DATA-FORMAT: JSON",
"X-PAYPAL-SECURITY-RESPONSE-DATA-FORMAT: JSON",
"X-PAYPAL-SECURITY-APPLICATION-ID: ".PAYPAL_API_APPLICATION_ID,
);
$ch = curl_init();
curl_setopt ($ch, CURLOPT_URL, $baseurl);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, TRUE);
curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt ($ch, CURLOPT_SSL_VERIFYHOST, FALSE);
curl_setopt ($ch, CURLOPT_POSTFIELDS, json_encode($data));
curl_setopt ($ch, CURLOPT_HEADER, $headers);
print_r(curl_exec($ch));
I created several test accounts under "Sandbox Test Accounts" on developer.paypal.com. I tried using their username + password + signature (from the API Credentials tab) in the code above.
Always getting "Authentication failed. API credentials are incorrect."
Edit 1:
On this page: https://developer.paypal.com/docs/classic/adaptive-payments/gs_AdaptivePayments/ they have a similar curl command. I run this command:
curl -s --insecure -H "X-PAYPAL-SECURITY-USERID: caller_1312486258_biz_api1.gmail.com" -H "X-PAYPAL-SECURITY-PASSWORD: 1312486294" -H "X-PAYPAL-SECURITY-SIGNATURE: AbtI7HV1xB428VygBUcIhARzxch4AL65.T18CTeylixNNxDZUu0iO87e" -H "X-PAYPAL-REQUEST-DATA-FORMAT: JSON" -H "X-PAYPAL-RESPONSE-DATA-FORMAT: JSON" -H "X-PAYPAL-APPLICATION-ID: APP-80W284485P519543T" https://svcs.sandbox.paypal.com/AdaptivePayments/Pay -d "{\"actionType\":\"PAY\", \"currencyCode\":\"USD\", \"receiverList\":{\"receiver\":[{\"amount\":\"1.00\",\"email\":\"rec1_1312486368_biz#gmail.com\"}]}, \"returnUrl\":\"http://www.example.com/success.html\", \"cancelUrl\":\"http://www.example.com/failure.html\", \"requestEnvelope\":{\"errorLanguage\":\"en_US\", \"detailLevel\":\"ReturnAll\"}}"
in a terminal window and got a payment created success response.
So next I switched the userid/password/signature in this command with the ones from the original question, and guess what, that worked too!
Finally I used the userid/password/signature from the example in the PHP curl code from my original question and again got the "Authentication failed. API credentials are incorrect." message.
To sum things up both userid/password/signature combinations (mine and Paypal's) generate a success response if run via terminal, but both produce authentication failure errors when run via my PHP CURL code. So there is definitely something wrong in my original code, question is WHAT??
Edit 2:
Still can't get it to work, but I'm thinking it's something to do with the headers bit. Here is why: take a look at the full response I'm getting:
HTTP/1.1 200 OK
Date: Tue, 13 Oct 2015 11:51:23 GMT
Server: Apache
X-EBAY-SOA-REQUEST-ID: 150610a6-a690-a488-6781-12e6ffa2f8dd!AdaptivePayments!10.72.134.120![]
X-PAYPAL-SERVICE-VERSION: 1.0.0
X-PAYPAL-SERVICE-NAME: {http://svcs.paypal.com/types/ap}AdaptivePayments
X-EBAY-SOA-RESPONSE-DATA-FORMAT: XML
X-PAYPAL-OPERATION-NAME: Pay
CACHE-CONTROL: no-cache
X-PAYPAL-ERROR-RESPONSE: TRUE
X-EBAY-SOA-MESSAGE-PROTOCOL: NONE
Set-Cookie: Apache=10.72.108.11.1444737084008373; path=/; expires=Thu, 05-Oct-45 11:51:24 GMT
Vary: Accept-Encoding
Paypal-Debug-Id: 32922591f3d33
Set-Cookie: X-PP-SILOVER=name%3DSANDBOX3.APIT.1%26silo_version%3D880%26app%3Dadaptivepaymentspartaweb_api3t%26TIME%3D1005591638; domain=.paypal.com; path=/; Secure; HttpOnly
Set-Cookie: X-PP-SILOVER=; Expires=Thu, 01 Jan 1970 00:00:01 GMT
Connection: close
Transfer-Encoding: chunked
Content-Type: text/xml;charset=UTF-8
<?xml version='1.0' encoding='UTF-8'?><ns3:FaultMessage xmlns:ns3="http://svcs.paypal.com/types/common" xmlns:ns2="http://svcs.paypal.com/types/ap"><responseEnvelope><timestamp>2015-10-13T04:51:24.021-07:00</timestamp><ack>Failure</ack><correlationId>e133487976d4b</correlationId><build>17820627</build></responseEnvelope><error><errorId>520003</errorId><domain>PLATFORM</domain><subdomain>Application</subdomain><severity>Error</severity><category>Application</category><message>Authentication failed. API credentials are incorrect.</message></error></ns3:FaultMessage>
It's XML why I specified JSON as the response data format. So if the response format line is ignored or not properly read I guess the same thing is messing the login details. Hope this is a good clue...
If you are 100% certain that the API Credentials for a business Sandbox account are correct then verify you have the correct App id. The APP Id needs to be the APP id from the application you submitted for Adaptive Payments.
If you have not submitted an application yet here are the instructions:
How to Submit a Developer Application
If you have already applied for Adaptive Payments go to your list of applications, and click on your application to verify the correct App id.

Paypal IPN callback stopped working in sandbox environment

I'm having a problem with the paypal IPN callback. Paypal's IPN callback stopped working, in sandbox environment.
I've been testing my client's website, for the past weeks, and it has always been working correctly - The payment was made, and a callback IPN was sent back to the website, confirming the payment, and updating the website's database.
I haven´t change anything in my code, and it suddenly stopped working. The payment is still made and saved in the paypal account, but the IPN is always retrying... it doesn't complete.
Here's the code in use:
<?php
// STEP 1: read POST data
// Reading POSTed data directly from $_POST causes serialization issues with array data in the POST.
// Instead, read raw POST data from the input stream.
$raw_post_data = file_get_contents('php://input');
$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 IPN message sent from PayPal and prepend 'cmd=_notify-validate'
$req = 'cmd=_notify-validate';
if(function_exists('get_magic_quotes_gpc')) {
$get_magic_quotes_exists = true;
}
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";
}
// STEP 2: POST IPN data back to PayPal to validate
$ch = curl_init('https://www.sandbox.paypal.com/cgi-bin/webscr');
curl_setopt($ch, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_1_1);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $req);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($ch, CURLOPT_FORBID_REUSE, 1);
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Connection: Close'));
// In wamp-like environments that do not come bundled with root authority certificates,
// please download 'cacert.pem' from [link removed] and set
// the directory path of the certificate as shown below:
// curl_setopt($ch, CURLOPT_CAINFO, dirname(__FILE__) . '/cacert.pem');
if( !($res = curl_exec($ch)) ) {
// error_log("Got " . curl_error($ch) . " when processing IPN data");
curl_close($ch);
exit;
}
curl_close($ch);
……
?>
Firing some outputs to text files, I discovered that it passes the first Step and stops on the Second, before
if( !($res = curl_exec($ch)) ) {
I've already submitted three help requests to PayPal, but still didn't get an answer from them.
The cURL request initiates a HTTP POST back to PayPal in order to validate the IPN message. If it stops at this step, it means you do receive the IPN POST from PayPal, but you've got a problem connecting back to PayPal.
What does // error_log("Got " . curl_error($ch) . " when processing IPN data"); contain?
In order to resolve this, test the HTTPS connection from your server to the following addresses:
https://www.paypal.com/cgi-bin/webscr?cmd=_notify-validate
https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_notify-validate
For example, you can run cURL directly from your server (assuming you've got SSH access);
curl -v https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_notify-validate
This should return something similar to the following:
$ curl -v https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_notify-validate
* About to connect() to www.sandbox.paypal.com port 443 (#0)
* Trying 173.0.82.77...
* connected
* Connected to www.sandbox.paypal.com (173.0.82.77) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: /usr/ssl/certs/ca-bundle.crt
CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using AES256-SHA
* Server certificate:
* subject: 1.3.6.1.4.1.311.60.2.1.3=US; 1.3.6.1.4.1.311.60.2.1.2=Delaware; businessCategory=Private Organization; serialNumber=3014267; C=US; postalCode=95131-2021; ST=California; L=San Jose; street=2211 N 1st St; O=PayPal, Inc.; OU=PayPal Production; CN=www.sandbox.paypal.com
* start date: 2011-09-01 00:00:00 GMT
* expire date: 2013-09-30 23:59:59 GMT
* common name: www.sandbox.paypal.com (matched)
* issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)06; CN=VeriSign Class 3 Extended Validation SSL CA
* SSL certificate verify ok.
> GET /cgi-bin/webscr?cmd=_notify-validate HTTP/1.1
> User-Agent: curl/7.28.1
> Host: www.sandbox.paypal.com
> Accept: */*
>
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
< Date: Wed, 14 Aug 2013 20:15:53 GMT
< Server: Apache
< X-Frame-Options: SAMEORIGIN
< Set-Cookie: xxxxx
< X-Cnection: close
< Set-Cookie: xxxx domain=.paypal.com; path=/; Secure; HttpOnly
< Set-Cookie: Apache=10.72.128.11.1376511353229960; path=/; expires=Fri, 07-Aug-43 20:15:53 GMT
< Vary: Accept-Encoding
< Strict-Transport-Security: max-age=14400
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=UTF-8
<
* Connection #0 to host www.sandbox.paypal.com left intact
**INVALID* Closing connection #0**
* SSLv3, TLS alert, Client hello (1):
If you receive a timeout or an SSL handshake error, you will need to investigate this separately.