Closed (fixed)
Project:
Commerce PayPal
Version:
7.x-1.x-dev
Component:
PayPal WPP
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
6 Sep 2012 at 17:39 UTC
Updated:
9 Sep 2015 at 15:05 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
michfuer commentedThe 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.
Comment #2
rszrama commentedI 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.
Comment #3
michfuer commentedGlad 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.
Comment #4
rszrama commentedAhh, 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?
Comment #5
michfuer commentedI'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:
Comment #6
rszrama commentedAlrighty, 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
Comment #7
michfuer commentedWorks 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 :-)
Comment #9
steveganz commented