PayPal IPN fails in v2.6.16

[alatak]

Hello

paypal plugin to 2.6.16.2
VM 2.6.16
J! 2.5.27

Same for me...No IPN order updates

strange , the version 2.6.16.2 is the same as the one from 2.6.14
can you check in the joomla > extensions manager > manage, the the plugin has been updated correctly (check the version number) ?

I am included in this post the file that changed: plugins/vmpayment/paypal/paypal/helpers/paypal.php

[Milbo]

Please test this package

http://dev.virtuemart.net/attachments/download/927/com_virtuemart.2.6.17_extract_first.zip

[volksman3]

I also have the same issue as the other users on this thread and the updated 2.6.17 did not fix, when i look at IPN history in Paypal it just says Retrying but no error.

Emails stopped being sent to admin and customer and also the order status is not updated from pending to confirmed.

I can confirm the paypal transaction works properly and both merchant and customer receive the email from paypal. 

Should also confirm i switched IPN notifications off to test without it and same result, no emails from VM and no status update.

Any ideas?

[falko1]

I update to 2.6.17. Verified in plugin manager. All is updated to 2.6.17
after some testings i can also confirm...

NO order status updated to confirm. NO Email to Costumer and Admin.
Paypal payment is confirmed by email from paypal to admin and costumer.

[optmax]

paypal plugin  2.6.17 (checked in Extension manager)
VM 2.6.17 Component & AIO
J! 2.5.27

Just the same results as falko1 - No order status update via IPN

[falko1]

I checkt the logfile and found a errror
See below:

2015-03-09 22:04:37 DEBUG PaymentNotification, order_number:: cf91016
2015-03-09 22:04:37 DEBUG PaymentNotification, virtuemart_paymentmethod_id:: 1
2015-03-09 22:04:37 DEBUG checkPaypalIps PRODUCTION:
2015-03-09 22:04:37 DEBUG checkPaypalIps REMOTE ADDRESS: 173.0.81.1
2015-03-09 22:04:37 ERROR checkPaypalIps: Error with REMOTE IP ADDRESS = 173.0.81.1.
                        The remote address of the script posting to this notify script does not match a valid PayPal IP address

[driver_wedge]

I'm having the same issue as you guys. I've been watching this thread with interest over the past week....hope we can find a cause/solution soon.

[Milbo]

Yeh but the question is, if you found the new option setting in vm config on the first tab.

The reason for your problems is that you are using a reversed proxy. I removed the uncertain headers, and we check now only for REMOTE_ADDR (the normal case), and X_FORWARDED_FOR which is very often used for ngnix and apache http://en.wikipedia.org/wiki/X-Forwarded-For. But any admin can set his own type. There are just some conventions.

If you know your header, just add it in the vmconfig and try again. For example this one X-Forwarded-Proto, we can add it, but we cannot add any by default, because they can be unsure, if there is no reverse proxy.

[volksman3]

Hi, I am not using a proxy and have the issues i mentioned in my post above in this thread, i know this is community supported and i am not a programmer and as such don't have the skills to fix this, that said i have customers that right now are not getting email notifications and orders are confusing as we have to manually check everyone one for payment with paypal as nothing is being updated to confirmed.

I don't have the skills to fix this, just report the issue but what i am happy to do is pay to get it fixed a i need the store to be working correctly so both customers and us get email notifications and know what status orders are at.

Would this help if i was to pay for a fix?

Regards
Tony

[falko1]

Thanks for the anwer.

Yes, i found a new field in the config tab.
But i don´t understand the reverse proxy settings. I´m not shure that i use this proxy.

Is there any Method to find out the proxy settings?

[Milbo]

Thank you volksman3, indeed it helps us a lot if you buy a membership http://extensions.virtuemart.net/support/virtuemart-supporter-membership-detail .

Also a common variable seems to be X-Forwarded-Proto

Please read here about Reverse Proxy http://en.wikipedia.org/wiki/Reverse_proxy

If you use a CDN, or if your server is using a load balancer, or when you activated it on your apache, or when use squid,ngnix, then you are using a reverse proxy. We do NOT talk about a proxy in a company, university or similar.

[volksman3]

No problem, i will buy a membership today for sure if it helps, i looked into tithe link you sent and i do have WHM access to our server etc but down know where to begin with this - are there any step by step instructions i can follow to fix this as this is way beyond me right now?

[driver_wedge]

Yeh but the question is, if you found the new option setting in vm config on the first tab.

Is this in VM 2.6.16 or 2.6.17....or both, perhaps?

Is there a simple reason why the Paypal IPN would suddenly not work any more? Has the updated VM component been changed in such a way that the IPN feature will no longer function under certain server environments? i.e. this is not a bug, but is a problem from the user end?

[Milbo]

Most paypal payments do not check if the confirm comes actually from a paypal server. So "we" added a check to ensure that only paypal can update the order. The problems appear if you use a reverse proxy. So when paypal connects your shop, then your shop is behind the proxy (not the client like a normal proxy). So vm gets not the client Ip, vm gets the internal IP of the server, usually 127.0.0.1 and therefore the IP validation fails.
The core is almost the same as vm2.6.14, the difference is now only that I added an extra config setting, so that people using a reverse proxy, cdn, loadbalancer or similar can enter the variable of their reverse_proxy.

Here is a simple explanation http://blog.haproxy.com/2012/06/05/preserve-source-ip-address-despite-reverse-proxies/ or look here
http://nginx.com/resources/admin-guide/reverse-proxy/ and there you can see the problem

Code Select Expand


location /some/path/ {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_pass http://localhost:8000;
}

in this case the right variable is X-Real-IP, despite the fact that X_FORWARDED_FOR is the convention, the reason it is a "defacto" convention, because a lot people use it, but not anyone. Additionally to that, it could be that, if you use  X-Real-IP, that php wants X_REAL_IP. I must admit I know about that only theoretically and never configured it myself.

There is maybe a simple method to find the server variable. Just use somewhere in a layout or so

Code Select Expand


vmdebug('My server variable',$_SERVER);


[volksman3]

Oh boy, thanks for the update but this is way beyond the average users head never mind the fact that most users don't even have access to there servers at this level and trying to get a host to make these changes who don't generally want to get involved is going to be a nightmare for allot of people, is there not easier way to get Virtuemart working again without the need for technical server configurations? I have used Virtuemart right since the day of its conception and have not had to do anything like this before, at best the odd patch and styling issues but this is way beyond and will put off allot of users?