29 replies to this topic

[Didier]

Hi All,

For the user of the Paypal module version 2.0 beta, i have make some bug correction and french language update.
This new version is the Paypal module version 2.1 beta and it works perfectly !

- Bug fix : Now the user get a email " Payment accepted" after PayPal validation
- French translation for the payment interface
- French translation for the paypal page link

You can find the Paypal version 2.1 beta in the zip file

Attached Files

•  PayPal_2_1_Beta.zip   15bytes   436 downloads

[Philippe Sang]

Some security holes inside ;)

[Didier]

less than in version 1.4 .. is not it?

[Philippe Sang]

No security hole in the module given by PrestaShop.

[Didier]

Could you tell me which hole type and i will try to solve it ? Thank you

[Philippe Sang]

Vars coming from post (strval(), intval() are missing).

[Didier]

HI

Version 2.1 beta 1 with security holes correction.

strval and intval added ! maybe too much ;-))

This modules is a evolution of the original module from http://www.ecartserv...ule-prestashop/

Attached Files

•  PayPal_2_1_Beta1.zip   14bytes   468 downloads

[pouet]

good job

[Paul C]

Great work by the way. It would be nice to modify the original on my site if that's ok to reflect these good modifications? I haven't had time to work on these myself for a while, so it's good to see that the community is still actively working on it. Full credit will be given, of course :)

From 1240928160:

No security hole in the module given by PrestaShop.

Wow now there's a bold claim :lol: I'm sure you didn't really mean to say that ;)

In validation.php the post variables are those returned by Paypal, and I don't personally see that they're a risk, given that they are generated by ourselves, posted by us to PayPal, returned by PayPal and then verified that they haven't been tampered with between PayPal and ourselves (via the IPN callback to PayPal in validation.php).

If PayPal returns invalid data, then there's an error in the transaction, so it could easily be viewed that forcing the type to an integer/string is actually bad practice, and better you would validate the values returned from PayPal to ensure that they are the correct type (e.g. numeric, non-zero) - if you really feel it's necessary at all - which it isn't in my opinion. The IPN mechanism is very hard to manipulate, unless you can modify the script as part of the exploit - in which case your intval() and strval() calls won't help you!

One of the problems with adding those intval() and strval() calls (certainly in the validation.php script) is that you're actually manipulating the data returned by PayPal and should there be a problem, you may well have lost valuable diagnostic data. I would certainly remove them from the debug entries, and log the actual POST variables at the very least.

Where this appears to still be open to manipulation is modification of the form posted to PayPal FROM the store, for example by changing the amount to pay (paypal.tpl) - the IPN return values should really be checked by the validation.php script to detect such manipulation. This isn;t as trivial as it seems, given that you potentially have to deal with currency conversions too.

As I said, good work and I'll have a look at the diffs to see what's changed and maybe see if there's anything else that could be added to make this even better :)

Paul

[Hoodgrown]

What does this module do differently... or does that 1.4 doesn't do?
Also, is there an English Translation or no?

[Paul C]

This was intended to get around lots of issues folks were having, by actually logging the responses from PayPal (other than just checking that the transaction was ok). It also creates an order BEFORE the IPN comes back - this has been an issue when PayPal have taken up to 15 hours to send an IPN to your store. The standard module will still show the products in the customer's cart, and no order in the front or back office until an IPN has been received.

The original is in english. I'm not sure if any new messages added are in english too, but I suspect that they are ;)

Paul

[Hoodgrown]

Sounds good... I wonder if the author can improve upon the Google CHeckout as well. I received my first order through Google and the order wasn't logged.

[kingsnake]

doesn't work for me - I get server errors:

MAIN error_log:

[Tue Aug 25 04:42:44 2009] [error] [client 72.231.19.192] SoftException in Application.cpp:256: File "/home2/shoptoyl/public_html/modules/blockcart/blockcart-set-collapse.php" is writeable by group, referer: http://www.myshop.com/

[Tue Aug 25 04:42:44 2009] [error] [client 72.231.19.192] Premature end of script headers: blockcart-set-collapse.php, referer: http://www.myshop.com/

[Tue Aug 25 04:42:44 2009] [error] [client 72.231.19.192] File does not exist: /home2/shoptoyl/public_html/500.shtml, referer: http://www.myshop.com/

[Tue Aug 25 04:43:02 2009] [notice] mod_fcgid: process /usr/local/cpanel/cgi-sys/default.fcgi(28349) exit(idle timeout), get stop signal 15

[Tue Aug 25 04:43:06 2009] [warn] RewriteCond: NoCase option for non-regex pattern '-f' is not supported and will be ignored.

The directories are all CHMOD to 777, IPN is also set up but no dice. Any ideas?

[Katmatcreations]

From 1247759072:

This was intended to get around lots of issues folks were having, by actually logging the responses from PayPal (other than just checking that the transaction was ok). It also creates an order BEFORE the IPN comes back - this has been an issue when PayPal have taken up to 15 hours to send an IPN to your store. The standard module will still show the products in the customer's cart, and no order in the front or back office until an IPN has been received.

The original is in english. I'm not sure if any new messages added are in english too, but I suspect that they are ;)

Paul

Wow 15 hours for IPN to arrive?

Has anyone raised that with paypal? That seems a little wierd, i know recently they did some upgrades and logging into the webserver was slow but 15 hours is a fairly long time!

[Neoasimov]

Hi here,


Quick question: is it normal that the only difference between this v2.1 and v2.0 is the new debug info in the validation.php file?

I am wondering is Paul or Didier did update the code on their side, which would then explain that there is no other differences between the files.


Otherwise, I don't see this fix "- Bug fix : Now the user get a email “ Payment accepted” after PayPal validation – French translation for the payment interface – French translation for the paypal page link" neither in the code, nor in action.


Thanks for helping me figuring out what is happening :)

[connexion]

I have been using the PayPal v2 beta from Paul for a couple months already. It works great. But one thing that I notice that when the customer click the PayPal link in the last step of the order, then the PayPal screen will appear.

If the customer pay straight away, the order is updated with 'Payment Accepted' status. That is as expected.

But if the customer decide to pay later, he/she closes the paypal screen. When the customer comes back to his/her order in the prestashop, the customer couldn't find the PayPal button in the order screen to pay.

At the moment, everytime such thing happen, I cancel the order and ask the customer to repeat the buying process again.

Is there anyway to make the PayPal button appear in the order screen if the order status is 'awaiting PayPal Payment'

Thanks.

I hope my explanation is clear enough.

[Xiao]

whats the difference between yours and ecartservices

[eknepfler]

Can anyone confirm that this module resolves the problem of orders not being saved into PrestaShop after clicking "return to site" from the Paypal screen, which results in the user being told they have not placed any orders, no orders in backoffice, and the order still in the cart, even though they just finished paying with PayPal?

Well I just tried it and got "order creation failed" as soon as the user clicks the pay with paypal button.

I guess Paypal is completely unfixable under Prestashop at the moment.

[AffordableFiberOptics]

Any ideas?


Hack attempt (OrderHistory -> id_order_state is empty)

Works okay on test server but I get that in production.

Thanks.
Patrick