[ic] Problem Maintaining Session

Bruno Cantieni interchange-users@interchange.redhat.com
Fri May 3 07:45:00 2002


----- Original Message -----
From: "Ed LaFrance" <edl@newmediaems.com>
To: <interchange-users@interchange.redhat.com>
Sent: May 1, 2002 4:45 PM
Subject: Re: [ic] Problem Maintaining Session


> At 01:07 PM 05/01/2002 -0400, you wrote:
> >Problem: Accessing session data after an offsite transaction approval.
> >
> >This has been discussed frequently on the list but after hours of
> >searching for a definitive answer,
> >I have not found one yet.
> >
> >I'm running IC 4.8.3 on an Ensim "powered" private server.
> >Red Hat Linux release 6.0 (Hedwig)
> >Perl 5.00503
> >Memory handicapped, but this is just a staging server.
> >
> >The development store (demo) based on the foundation catalog is working
> >perfectly.
> >I'm trying to implement a transaction clearing mechanism with our Canadian
> >company "InternetSecure"
> >(mentioned a few times on the list as well but no one seems to have done
> >this one successfully).
> >"IntenetSecure" is in essence a "Master Merchant" whith whom we have an
> >account and are processing
> >transactions from other stores succesfully at this time. None of these
> >stores are based on IC.
> >
> >Similar to PayPal and others, we pass some required merchant and store
> >variables along with cart
> >contents and shipping costs via product strings to InternetSecure, which
> >then captures the credit
> >card information, calculates applicable taxes and does the authorization.
> >We then have them fire back an approval string with their "post approval
> >script" (on approved
> >transactions only) with all the pertinent data.
> >
> >We are attempting to process and complete the order with a special page
> >"postapproval.html" which
> >essentially duplicates the functions of log_transaction, mail_receipt,
> >report etc.
> >
> >
> >So far so good, we have all this working.
> >
> >Here is where I get stumped:
> >
> >Passing back the session id to a page which would then log the order and
> >fire off the necessary
> >e-mails, is not working. A new session is always generated, hence we don't
> >have the "old" session
> >data available. I have tried various suggested approaches.
> >Sending back the the session id in the IC format
> >http://serverurl/catalog/ord/postapproval?id=nnnnnnnn&etc&etc...:
> >
> >id appears to get ignored or stripped; [cgi id], [value id] are blank;
> >[data session id] shows a new
> >session.
> >
> >Sending the session id to the processor and back as sessionvar=[data
> >session id] works; [cgi
> >sessionvar] shows the proper session id.
> >
> >Using another suggested approach (courtesy MH) in conjunction with the
> >above of setting up "Variable
> >MV_SESSION_ID sessionvar" in the catalog.cfg still gets me nowhere.
> >
> >If I plug the postapproval URL directly into a browser while I still have
> >a window open with my cart
> >(http or https) works as expected and does the required post approval
> >processing. Doing the same
> >with a different browser does not,
> >Cookies seem to make this work and having the store run in secure mode
> >also seems to help.
> >
> >Any ideea as to how to make this work?
>
> Calling a return URL to your store which contains a valid session ID string
> should work - I have written implementations which do this without fail.
> Something else is going on; perhaps the return  URL is being munged
> somehow; or perhaps IC refuses to recognize id=nnnnnnnn on a cookie-enbaled
> browser. Try building your return url as a form instead of a regular link,
> i.e.:
>
> [seti return_url][area form="
>                                  mv_todo=return
>                                  mv_nextpage=ord/postapproval
>                                  extra_var1=some_data
>                                  extra_var2=more_data
> "][/seti]
>
> Then send [scratch return_url] to your payment processor with the other
> data. The session ID will be included automatically and should be
> recognized by IC on the return (and invoke-able with [data session id]).
>
> - Ed L.
>
>

Thanks, Ed.

I may not have made myself clear. I have no problem generating a working return URL i.e. a link or
button the customer has to click on to get back while still on the card processors site and I can
get such a link or button to complete the order  IF CLICKED.
Therein lies the problem. While some customers do, I don't trust the customers enough to click the
link. She has done her shopping, the purchase has been approved; why should she???

So we take matters into our own hand and try to make sure the transaction gets completed regardless.
As soon as the transaction has been approved, the card processor sends out a useragent in the
background to communicate with whatever script you want  to run (in our case back to the catalog
script) for loging the transaction or whatever other postapproval stuff you wish to do. As far as IC
is concerned, it sees a new browser, accessing the store from a different location/IP. Of course it
would issue a new session to this browser object.

The question then is really, how can I get IC to NOT issue a new session but rather use the session
being fed to it by this "browser".

As indicated in my original post, we process several (development and staging ) stores through a
single account with InternetSecure. We do this by having the useragent generated by the
"ExportScript" at InternetSecure pointed at a central script on our own server which simply parses
the incoming data (using good old cgi-lib), determines which store to re-direct it to, create our
own useragent and simply fire the entire string off as per

sub LogICDemo {

use LWP::UserAgent;
use HTTP::Request;
use HTTP::Response;

$ua = new LWP::UserAgent;
$req = HTTP::Request->new("POST", 'http://www.thisdemostore.com/cgi-bin/demo/ord/postapproval');
$req->content_type('application/x-www-form-urlencoded');
$req->content($form_data); # All the data coming back from the card processor
$response = $ua->request($req);
print "Response is:".$response->as_string()."\n";
}

This works great for all the other stores (none IC based) and we simply parse the incoming data,
grab the the session id, open the relevant session file and complete the cycle (log, email, ditch
cart etc.). We also create a session "marker", so that if the client does click the return URL link,
we can determine from the marker file what to show next to the client (eg. a receipt page or a page
telling them that there was a problem etc.).

I had hoped there was some built in capability I could use other than going the route just described
above.
Ah well.

Thanks anyway.

Bruno Cantieni

PS
(cfm/Racke) RH6/perl 5.00503 are not my choice but this is what this "private" server is set up like
with my HSP.
"Private" here means a shared box with your own partion, giving you a virtual dedicated server.
They use the  Ensim ServerExchange/WEBPliance to run the thing (which we really like BTW), alas, it
wont run under Perl 5.6+; I tried :(

So far we have not had any problems with this setup; it's just memory challenged, frequently running
out and creating forking issues. (I guess that should be non-forking issues) We are upgrading
shortly; fully dedicated box with more gigs, more RAM and more MHz:)

###########################################
Bruno Cantieni
Digital Landscape - Cyboretum.com
Web Applications * Web Hosting * e-Commerce
http://www.digi-land.com
http://www.cyboretum.com
bruno@digi-land.com
Phone/Fax: 905.668.2255