[ic] Problem Maintaining Session
Ed LaFrance
interchange-users@interchange.redhat.com
Fri May 3 11:02:00 2002
At 07:54 AM 5/3/2002 -0400, you wrote:
>----- 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";
>}
I think I will go with my original answer. In this context, what happens if
you change the above request to a 'GET' and pass the session as
mv_session_id=nnnnnnnn ? I am sticking with this because it is the only way
I have tried it.
This is also a good illustration for why, sooner or later, you have to
yield to the logic of a direct response system, like on of the several
gateways that are already supported by Interchange. The gymnastics for
handling systems like the above just get too exotic after a while.
- Ed L.
>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
>
>
>_______________________________________________
>interchange-users mailing list
>interchange-users@interchange.redhat.com
>http://interchange.redhat.com/mailman/listinfo/interchange-users
===============================================================
New Media E.M.S. Software Solutions for Business
463 Main St., Suite D eCommerce | Consulting | Hosting
Placerville, CA 95667 edl@newmediaems.com
(530) 622-9421 http://www.newmediaems.com
(866) 519-4680 Toll-Free (530) 622-9426 Fax
===============================================================