WorldPay Module for ZenCartv1.3x

One Very important thing and Alan Duncan should be reading this,

THEIR ARE PEOPLE HERE WHO JUST UNZIP THEIR FILES. :beta:

I.e. they are leaving a file in their directory structure which still has an exploit in it, so you should create a blank 0kb file, so that when the copy or ftp their files across they wipe it out.

Alan, are you any further forward with this?

Regards
AfterHouR

Hey Guys,

I'm nearly there with my installation with WorldPay on ZC, but it's constantly dogged with errors leaving me confused about what Ive done so far, and what I have to do.

Simply put, I need advice on the following points (please!)

1. Worldpay Returning to ZC - It doesn't do anything! No redirect or anything. I've searched this thread and can't seem to find anything that answers it.

2. The "https://<wpdisplay item="MC_callback">" payment response - the url is set to the url of the website, and when I try to change it back to this, i get a 'database error' from World Pay.

3. So I guess without point 1, the order isn't going to hit the database and update on the admin area, which it doesn't.

Any help would be appreciated.

Thankyou :lookaroun

Hello the module is not mine but I do some of the work, PM me with the database error so I can have a look, as it's best not to publish those things, we can sort out the re-direct afterwards.

Philip.

thomas - I am sure Philip may have sorted you out by now, he's a star however I had similar troubles and the fixes were quite simple:

If you don't log into Production in Worldpay admin setup then you get the database error. Log in to production, edit in Production and then switch to Test using the button at the bottom of the page if you want to edit the Test setup.

Don't add the URL of your site - add the <<wd_display... string as you are trying to do but make sure the first 3 box options are ticked.

Regards

Ahh, now this is where I admit I am flawed since I do not have worldpay access. I advised him to lok through his logs to see if the worldpay java object is attempting communication with his zencart shop (which it wasn't but the advice is still valid).

Thanks Snow-man, for covering the bits that I can't reach.

Wow - this has been a busy thread.! Glad to see that some are taking note of this module. My apologies for any errors.

I'll try to cover the various points in order:

1. MD5 coding error.

Oooops! Sorry - so that's why I couldn't get it to work. And here was me thinking my host hadn't set up the MD5 functions correctly.
I do apologise - but I did say in the installation notes that I had not tested it. And until now neither had anyone else!

2. To 'SSL' or 'NONSSL'

The following is a quote from the installation notes included with the beta fileset:

4. In the WorldPay admin screen click 'Configuration Options' for the installation i.d. (usually bottom of screen). Enter the Callback URL exactly as follows (including case):

https://<wpdisplay item="MC_callback">

N.B. If SSL is not enabled on your website the Callback URL should be:

http://<wpdisplay item="MC_callback">

 Also in /includes/modules/payment/worldpay.php:

 Un-comment out lines 134 & 135
 Comment out lines 136 & 137

Since these notes were written WorldPay changed the way it handles test and live transaction - they are now directed to separate URLs rather than just relying on the 'Test Mode' value to direct the transactions appropriately. I therefore added the code at lines 53 to 60 to handle this. This moved the rest of the code down so the last two lines of the above should now read:

" Un-comment out lines 140 & 141
Comment out lines 142 & 143"

I think you will find that this works perfectly adequately - although Philip's method is more elegant.

I agree with Philip that it would be better to pick this up automatically but in my defence the default is SSL as this is how it should be configured. What is anyone doing passing customer name and address details insecurely over the internet! I don't make any apologies for making it difficult for someone to do this insecurely.

In any case I have limited time to support this module as it is.

'SSL' is not superfluous as this sets the path to the secure server which may not be the same as the path to the non secure server. The path to the secure server is set in the configure.php file. For some (those with their own security certificate) the two paths will be:

http://www.myserver.com
https://www.myserver.com

but for those using a shared security certificate the paths may well be:

http://www.myserver.com
https://secure.sharedserver.com/www.myserver.com

Just replacing 'http' with 'https' will not work.

3. The Missing $zenId

It's not missing - I deliberately removed it. The session ID is passed to WorldPay as cartId - see lines 124 and 135. WorldPay pass this back along with callback URL. When the $zenId was included in the callback URL it got included twice. Now that is superfluous!

4. Blank Obsolete Files

Now I never thought of that. Good idea - but what about those who are installing the module for the first time? They will end up with a lot of empty files on their server for no reason. I'll give it some thought before the next release.

LASTLY

Basically the module works out of the box if the installation instructions are followed. Don't muck about with the callback URL or try to set anything different from

"https://<wpdisplay item="MC_callback">" or
"http://<wpdisplay item="MC_callback">" if you must (but remember to make the code changes as per the installation instructions).

Implement the security features and welcome your customers to your store.

The most common problem people have is callback failure. My opinion is that this is invariably caused by the host server configuration. Ask your host if they maintain sessions. If they say 'No' or don't know - move to a host that does know and says 'Yes'. I have allowed several people with callback problems to test their sites on my server. In every case the module worked first time.

I hope I have covered everything and that this helps clarify things.

Thanks to all for your comments - especially for pointing out the error to the MD5 code. Obviously there is a need for the module out there or this thread would not be quite so long. It's nice to think that I might have been able to contibute in my own small and flawed way.

Regards to all,

Alan

duncanad:

2. To 'SSL' or 'NONSSL'

The following is a quote from the installation notes included with the beta fileset:

Since these notes were written WorldPay changed the way it handles test and live transaction - they are now directed to separate URLs rather than just relying on the 'Test Mode' value to direct the transactions appropriately. I therefore added the code at lines 53 to 60 to handle this. This moved the rest of the code down so the last two lines of the above should now read:

" Un-comment out lines 140 & 141
Comment out lines 142 & 143"

I think you will find that this works perfectly adequately - although Philip's method is more elegant.

So do I, that was written after the "remove the SSL" comment as I had a gentleman with SSL and NOSSL at differing locations as you exemplify below.

duncanad:

In any case I have limited time to support this module as it is.

Yes I have been up to 2AM every morning helping people with this.

duncanad:

'SSL' is not superfluous as this sets the path to the secure server which may not be the same as the path to the non secure server. The path to the secure server is set in the configure.php file. For some (those with their own security certificate) the two paths will be:

http://www.myserver.com
https://www.myserver.com

but for those using a shared security certificate the paths may well be:

http://www.myserver.com
https://secure.sharedserver.com/www.myserver.com

Just replacing 'http' with 'https' will not work.

As mentioned above that's why I'd be elegant !

duncanad:

3. The Missing $zenId

It's not missing - I deliberately removed it. The session ID is passed to WorldPay as cartId - see lines 124 and 135. WorldPay pass this back along with callback URL. When the $zenId was included in the callback URL it got included twice. Now that is superfluous!

Ah, but the exploitable version also had the cartId as the zenid and yet didn't use it to re-establish the session (it wasn't supposed to) and there wasn't the time to check whether the beta was "working", so quick fixes were made to be 100% sure.

duncanad:

4. Blank Obsolete Files

Now I never thought of that. Good idea - but what about those who are installing the module for the first time? They will end up with a lot of empty files on their server for no reason. I'll give it some thought before the next release.

ZC themselves have "obsolete" files like index.html in includes/ that is to stop directory listing in case the .htaccess files work. I say blank them with a <HTML /> single tag in a page. I think because the define has changed then the old pages will fail, as one of the important constants has certainly altered.

duncanad:

The most common problem people have is callback failure. My opinion is that this is invariably caused by the host server configuration. Ask your host if they maintain sessions. If they say 'No' or don't know - move to a host that does know and says 'Yes'. I have allowed several people with callback problems to test their sites on my server. In every case the module worked first time.

A handy hint is that if worldpay fails with a 302 error, it means the password is wrong in either worldpay or the admin section, and your zencart installation is treating worldpay as a hacker.

Ok guys. Thanks to the genius working of Phil, I've got it working.

Basically - Follow the instructions on this post:

http://www.zen-cart.com/forum/showpost.php?p=619330&postcount=422

And ensure the WorldPay url is set to

https://<wpdisplay item="MC_callback">.

The result of this fix isn't final, I'll stress that. I did it on a test transaction and I'm about to try it on a live one.

If you read a news report of "Man in Manchester office block hangs himself with keyboard wire" then you know it's failed.

I did offer you more help than that, but you went all quiet and shy, I thought you'd already done the keyboard thing.

Jon>:

I wish mine had gone so smoothly - tried everything and I still get this callback error, both for cancelled and completed transactions in test mode.

Completely stumped now....

Smooth? Haha.

You looked at 53 and 54 on worldpay.php? There might be a line quoted out which could be useful.

That was my first issue anyway, that I was sending myself to the wrong url.

Oh and just to update you all, my live transaction did not work :-(.

I'm getting the old "This was NOT a live transaction - no money has changed hands." error message, which probably means I'm caught up with everyone else who are so close.

I'm getting returned to the site now. Hold on, I'll pm you my working worldpay.php.

Hello "jon" PM me and we'll talk a little while, maybe find out what's happening.

the main problem is that Zen have a "Recommended Services" page on their website for International Merchants to view

http://www.zen-cart.com/index.php?main_page=infopages&pages_id=39

and most people go with Iridium or Nochex

If we can get Worldpay to work really well before Xmas, we should be able to convince Zen to add Worldpay to this page, that in itself would put a lot of confidence back into the Worldpay module that Alan wrote 2 years or so back :smile:

Peter

The worldpay module is safe secure and ready, but the best bit is that the main myths that have plagued this thread have been solved mainly due to the patience of jon> during a 36 hours bug tracking session. He put up test files on a server for me up til 3AM last night and from early this morning till afternoon when we worked out the diagnosis and the cure.

The disease is worldpay dropping the sessions and not being able to tell the ZC shops that orders have been paid for, or retunring people to the shops. All those work around's and the fault on shared hosting is not due to this module, it's due to server configuration and the adding of extra "secure" php hardening modules. In ZC admin, configuration sessions, there is the ability to share sessions, this is needed by worldpay.

What happens is this:1. You happily shop
2. Your shopping cart is stored with a handy reference number called a session
3. The session and amount you have to pay is passed securely (now) to worldpay
4. Worldpay takes payment and hands the reference number back to the shop so that the shop owner knoes you've given the money and can ship your goods.

In the "disease" the reference number was doing nothing when worldpay passes it back. This diagnosis took a very long time and went through worldpay code, through ZC's core code and in the end to the heart of php and how some companies have se up their virtual hosting. The companies are adding a module to php to make it more secure, this sits in the background and is not visible to zencart. It encrypts the session details, it also links them to a web browser and ipaddress.

When Worldpay hands your zencart the reference number, this hardening tool kills the session before zencart can retrieve the details from the database, and so zencart never knows that worldpay was trying to pay. A hack is to really pass the session number through a different variable, then pull the details out from the database, and those talented people that wrote that hack should be congratulated for being able to work around a disease without knowing why it was happening.

In the case I was working on, it's called suhosin and I have "cured" the disease on one server so far. I can also write tools that will spot if the disease is present and inform shop administrators of how to work around it, because in this case techincal support of the virtual hosting company didn't know how the additional php module worked and what it was doing.

jon> has been great, I have 500 odd debugging emails from scripts he put up on the server as we followed the path from worldpay to the core configuration of the server. So the really funky news which is why everyone should dance, is that there's bugger all with Alan's or my secure sections of code. Worldpay will be ready by this weekend. Tomorrow I am being electrified for my own good in the morning so will be slightly unavailable but then will work on unifying the beta code and the security fixes for a single module installable module and then I'll work on the instructions and the warning system in case one is in danger of catching the "dropped session" disease and a vaccination.

Thank you
Philip.

great news, well done Jon & Philip, tremednous :clap:

What is the name of the offending PHP module that does the hardening bit without realising that is messed with Alan's code ?

silly me - I found it - Suhosin

http://www.hardened-php.net/suhosin

That may not be the only module, but now we know what we are looking for (strangely encrypted sessions in the database is one big giveaway now) and it only requires a small config change to make everything work so everyone should be dancing.

What's interesting is that it protects php invisibly on a virtual host, because the bulk hosting end of the market has no access to their log files so can't see that something is examining their sessions for possible security issues and then locking down. It would be a great piece of software for running WorldPay itself, as it stops people intercepting sessions URL variables or session cookies, so if one only need to stay in the same website it's fantastic, it's a right bugger when you need WorldPay to talk outside of it's box and it doesn't inform you that it's going to cut the lines of communication.

That jon> bloke, seriously, he has done a sterling effort, because he could just have walked away from WorldPay and we would never have known the answer and the same old "I don't get told a payment's been made" or "my session's being dropped" or "I have a redirect failing on line 22 because the headers have already been sent". ALL of these bugs can be caused by that additional invisible module. (some of them can be caused by people being silly too, but hell, I'm one more step closer to enlightenment ).

Philip.

sterling work Jon and Philip, good to know that we have chaps like you around who can persevere with this sort of stuff and come up trumps :bigups: