The billing address check in commerce_paypal_wpp_submit_form_submit() is always evaluating to TRUE (i.e. claiming invalid billing address). The problem is using the assignment operator in the if() statement with && instead of AND.

Also I was having trouble getting the WPP component to work and it turned out that the drupal function ip_address() is returning the IPv6 version of localhost '::1' instead of the IPv4 version '127.0.0.1', which the Paypal WPP API requires. Using a MAMP stack I couldn't for the life of me get ip_address() to give me the IPv4 version. Here's a similar issue: http://drupal.org/node/1500182#comment-6330890.

Comments

michfuer’s picture

Status: Active » Needs review
StatusFileSize
new3.82 KB

The following patch addresses both of the above issues. I added an IPv4 check in the patch because I think it might help developers more quickly identify any IP version issues. It appears that currently Paypal WPP API only accepts IPv4 addresses so I figured the module might as well check that before sending out it's request.

rszrama’s picture

Title: Billing address error and IPv4 requirement » PayPal WPP requires IPv4
Status: Needs review » Needs work

I noticed the address bug and committed a fix in http://drupalcode.org/project/commerce_paypal.git/commitdiff/451e09c. Thanks for reporting, though - pretty big goof. :-/

Let's go ahead and pursue the IPv4 fix a little further, though. What's interesting is my MAMP uses 127.0.0.1 just fine, but I don't believe I've changed anything. However, if we know ::1 is equivalent to 127.0.01, why don't we just convert it ourselves when preparing the API request? I don't see any reason to simply prevent the transaction from happening at all, especially since it's going to be a test transaction coming from localhost.

michfuer’s picture

Glad to help out.

I did notice one thing in your referenced commit (line 197). Should $billing_address_found instead be $valid_billing_address? Those conditions were part of the original if() statement, and it would seem should follow the pattern of setting $valid_billing_address to FALSE.

I think converting the IPv6 of localhost to IPv4 is a good idea. Preventing the transaction doesn't get one farther along in testing Paypal. They might just end up burning a lot of time trying to get MAMP configured, or hardcoding 127.0.0.1 into the .module file to get it to work, which I did both of :-)

Also, I think keeping an IPv4 general validation function is a good idea. Something like: if ip_address=IPv6 then check if it's localhost, if it is then convert and proceed with transaction, if it isn't then prevent transaction and post error message. This way if somebody is developing on a hosted server they could figure it out with their provider.

rszrama’s picture

Ahh, crap. You're right; I originally called it $billing_address_found but then changed it to $valid_billing_address because I meant to go back and ensure all required address values were actually in there. Posting a follow-up commit right now.

And I agree with you - let's just convert the IPv6 for localhost. Can we trust ip_address() to always return ::1 for localhost in IPv6 or should we actually find a conversion routine and then compare it to 127.0.0.1?

michfuer’s picture

I'm not familiar with the possible ranges the loopback address can have in IPv6 (or what the standard format is), but it seems like ::1 is the only one. The IPv6 loopback block is given in CIDR notation as '::1/128. Here's what the mighty Wikipedia said:

" ::1/128 represents the IPv6 loopback address. Its prefix size is 128, i.e. the size of the address itself, indicating that this facility consists of only this one address."

http://en.wikipedia.org/wiki/CIDR_notation

One possible solution I was thinking of:

$ip_address = ip_address();

//is it IPv4? 
if (filter_var($ip_address, FILTER_VALIDATE_IP, FILTER_FLAG_IPV4)) {
//proceed with transaction
}
  else {
  //is it localhost? This is the tricky part...
  if ($ip_address == '::1' //???) {
    //convert and proceed
  }
  else {
    //post error message
  }
}
rszrama’s picture

Status: Needs work » Fixed

Alrighty, I went ahead and did as you recommended with respect to converting ::1 to 127.0.0.1 with a warning but preventing submissions elsewhere. Took a slightly different approach, as we have a new pattern in the function for validating a variety of data. Shown in the commit.

Commit: http://drupalcode.org/project/commerce_paypal.git/commitdiff/5cdfd58

On a side note, doing testing I turned up yet another silly mistake in the address validation code. : P

Commit: http://drupalcode.org/project/commerce_paypal.git/commitdiff/827a199

michfuer’s picture

Works great on my setup! Transaction was processed, and watchdog logged the warning that my localhost was converted. Looks like the Paypal module is on the road to world domination :-)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.