How does Zencart re-create the Session from zenid, say for a callback URL for payment

Hi all

Does anyone know how the Zencart Session can be re-created from a callback POST sent with the zenid in it, from a payment gateway? I am creating a custom payment module for a little known payment gateway, but I think the $_SESSION['customer_id'] check is preventing it working.

I was told the zenid should be passed back, which it is, although its called $_POST['donorref']. but I cant see how the session would be recreated from this. Does anyone know?

P.S. I have asked this question elsewhere (http://www.zen-cart.com/forum/showthread.php?p=745593#post745593) and Phil has very kindly helped me out but I didn't want to fill up his Worldpay support thread. Sorry if this is double posting.

donorref' is going to have to be translated into zenid for the session to be re-established so a simple intermediary page where

Will do it (or a similar page) but with regards to the adapting of my modules to do this, the system will throw you out if you don't have a password to get back in and unless you disbale it entirely.

Thank you

Philip.

This is a big help... so the zenid has to be in the URL and Zencart recreates the session.

I have now got the Callback working from the payment gateway using the above line in a file (after various security checks). So thanks very much.

But now, after this happens and the cusomter clicks to return to the store from the payment gateway, it creates a duplicate order! The return URl for the customer is index.php?main_page=checkout_success. I thought as the callback processed the order it would not process it again on this page, but it does. -

We talked about how it recreates and how the model works, but you never completely explained whether it was a browser that would be trigerring the successful payment or a post from the payment gatery. Plue there's an error in the above. There should be **exit; ** after the header line.

I would [I]guess[/I since I haven't seen it etc... that your browser it returning the "I've been paid" result and it has a cookie, so without the "exit" added above, the session is being recreated and marked as paid, while it goes off and adds the donorref which then pays its again. The exit will cure the duplication probelm (must be happening damn fast though for teh order not ot have been deleted while the header is set) and you will still need the donorref because not everyone has cookies working and would surf the entire site with the url in the title.

It does stiill sound like you have a security problem though, if there's no unique feedback or encrypted reference posted from this mystery gateway, then there is nothnig stopping a person visiting the page driectly with their browser, posting the information and marknig an order as paid without visiting the gateway.

Thank you
Philip.

Actually I think its working now, just needed to get my head around checkout_success, checkout_process, and how zencart processes the order using zenid etc.

So I think its all working. Going to run a few more trials.

Basically I now have a callback.php file used for the payment gateway callback, which does a check to make sure the request comes from the payment gateway and if payment was a success, and if both these pass, it redirects to:-
index.php?main_page=checkout_process&zenid='.$_POST['zenid'].'

If it fails the checks it does nothing at the moment.

Adding the zenid on the end means Zencart knows what the order is for and now processes it.

Then when the client clicks on the Return to Store button, they are redirected to:-
index.php?main_page=checkout_success OR
index.php?main_page=checkout_payment

The first one shows the summary of the order they just made, which was processed by the callback POST.

So it seems to work fine.

you never completely explained whether it was a browser that would be trigerring the successful payment or a post from the payment gatery.

The problem I have had is the system uses Callback POST AND redirects the user back. Initially I was relying on the user coming back to the site to trigger it, but some people were not clicking on Return to Store. An old problem when not using Callbacks I guess you know. So I started to use the Callback but couldnt get the payment gateway to recreate the session. So thats done now thanks to your help.

Plue there's an error in the above. There should be exit; after the header line

I have added that now, thanks.

if there's no unique feedback or encrypted reference posted from this mystery gateway, then there is nothnig stopping a person visiting the page driectly with their browser, posting the information and marknig an order as paid without visiting the gateway.

I have a security key to check against if the POST came from the payment gateway and thats working. But how do you get around this in the checkout_process file? I notice if I go through the the Checkout process to Step 3, then just go to index.php?main_page=checkout_process directly, it processes the order anyway, so I am not on any custom page I have created at all, its all been Zencart pages, so thats a problem isnt it? How would the checkout_process page know whether payment has been made, my callback file does the check, not checkout_process :ohmy:

Just to summarise that last post as its long, the callback is working, but that very last point is an issue I cant see how to fix?

Oh dear I spoke too soon, call back not working anymore :(

It seems the header('Location: index.php?main_page=checkout_process&zenid='.$_POST['zenid']);

is not working because if I enter the full URL with zenid in another browser that I am not logged in with it processes the order OK. So seems the payment gateway is not following this redirection.

Oh well will come back to it again later.

The one major flaw is that you just change URL's in the title bar and it mark the order as processed. WHat you need to do if set one of the mthods in the payment module to return false and redirect to the login page (followed by exit after the header) before the order is processed.

There are various is a hook in the module to enable you to do this called $payment_modules->before_process(); this can check that the amount is correct, that the password or encryption coming back is okay, and if it fails it should redirect before the page checkout_process.php reaches the line

$insert_id = $order->create($order_totals, 2);

poor payment modules (in particular on oscommerce) do not use the method correctly and so if I or anyone else wanted to go on a spree, I'd send out fake emails from the gateways (a trivial thing to do) along with changing the urls in the browser window which would mark the orders as paid. Unless the shop owner religeously checks their payment gateway by logging on, then it's very easy to send out orders only to find out afterwards that there is no cash in the back. (this is similar to the worldpay exploit that I discovered as well as 7 modules on oscommerce, the difference is that the ZC team did something about whereas the bugs still exist on oscommerce). Interestingly I have yet to find a security PCI scanner that deals with this issue by any manufacturer who claims to make a shop more secure, certainly none of them have contacted me about the exploits.

Philip.

Posted via Mobile Device

Thanks for that, I'll try it over the weekend. You would't have an idea on why the header location redirect would not work when the payment gateway calls it would you? It works when I call the callback file in a browser (using some temporary test variables in the URL to by pass security checks for testing this). So I am positive it's all correct, it just doesn't work when payment gateway calls it.
Posted via Mobile Device

ONe of the things we went over in the beginning of this thread was the configuration of sessions. You should try it out with a different browser on the same computer to see if that works, as a basic initial test. You may also have a module called suhosin installed, and probaby the best thing to do after discounting those possibilites is to see what's being sent through from the gateway by writing it to a log file or mailing it to yourself.

The gateway may also not support redirects with headers too.

Sorry should have said I have checked all settings, they are as stated in beginning, and the data is being written to a log file ok. Seems everything works fine but for the gateway it stops ant the header location redirect. Untried it using a different browser and it worked, hence me thinking it's the gateway. I will check suhosin later but it seems it may be your last point, I will ask them. After all this work it would be just my luck to then have this issue! I wonder if curl would work instead? I will try later.

The gateway allows a variable to be passed back in it's URL, but it prefixes it with M_ so the zenid can be passed back in the URL as M_zenid but don't think that helps.

Alternatively I wonder if I could just add $_GET['zenid'] = $_POST['zenid'] to the top of my template file or something.

I'm sure I'll get there, will work on it later. Turning into a real nightmare! So appreciate your help in this.
Posted via Mobile Device

The only reason a redirect was suggested as a solution was because at that time you only had a donorref variable containing the zenid and things has changed in what you can pass through now so you can probably dump the header is you can repost the information. Not knowing what you have, I can only hazard a guess on the information provided.

Philip.

What do you mean by "repost the information"? Do you mean the callback file can repost the zenid to checkout_process? I thought zenid had to be in the URL, I.e. Using GET not POST.
Posted via Mobile Device

zenid has to be somewhere, cookie, $_POST or $_GET. The worldpay module uses it as a $_GET because that's what it does

The page includes/init_includes/init_sessions.php

if (isset($_POST[zen_session_name()])) {
  zen_session_id($_POST[zen_session_name()]);
} elseif ( ($request_type == 'SSL') && isset($_GET[zen_session_name()]) ) {
  zen_session_id($_GET[zen_session_name()]);
}

it's always been more than a little debeatable as to whether this gateway should be based on worldpay rather than any other payment module.

Ok. Will be trying all this later. You're right about worldpay. The payment module and form was based on worldpay and works well, but following your help the callback process is different now.
Posted via Mobile Device

Ok, a little update...

I tried using CURL, still no joy. So after placing an order (which was not updated in Zencart due to callback not working) I used logmein to login into a computer elsewhere, and went to the URL:-
http://www.kcm.org.uk/shop/index.php?main_page=checkout_process&zenid=xxxxxxxxxxxx (where xxxx is the zenid)

and it didnt work on that computer. It stated "Whoops session expired". But when I entered this URL on IE7 on this machine (I was not logged in as customer on IE7 but I placed the order on Firefox), it worked!

So it seems to work OK if on this computer, but doesnt work when another computer calls the URL. That may be why header() is not working and the whole problem.

The check IP setting is false. Here are the session settings:-

Session Directory /home/mysite/public_html/shop/cache
Cookie Domain **True **
Force Cookie Use **False **
Check SSL Session ID **False **
Check User Agent **False **
Check IP Address **False **
Prevent Spider Sessions **True **
Recreate Session **True **
IP to Host Conversion Status true

You could check under your server/ version tab to see if you have suhosin on that machine, if so you can disable it by using a .htaccess file. I'm still not convinced that the header is not causing the mystery gateway to fail as most would not acce[t a redirect.

Philip.

I dont have suhosin
:frusty:

would CURL be OK instead of header(). I have changed it to that to try in case the payment gateway does not support header redirect.

The payment gateway is called CPTerminal, http://www.ctt.org/. Aimed at charities. The support they are providing is fantastic, as is yours of course, but I dont think they can do much more. The Callback is being called, its recording the POST information in a log file. Then it stops at header() redirect :cry: I have asked them if their server supports header() redirect or not but probably wont get a reply until Monday.

Might be an obvious question, but why would you need the header redirect now ? Previously before the "exit" statement that I forgot to put in, you were having the order appear duplicated as it processed the information, the header was there to translate the donorref through to zenid, but apparently you don't need that now, so from where I am sitting, you can probably leave it out or at least bodge in init_sessions another line of code to recreate the session from the donorref.

Philip.