I have a site that is using WorldPay as it's paymnet gateway and I have set up Ucommerce to use this pipeline. Everything is fine up to the point where the Checkout pipeline kicks in and I seem to lose my session varibables. I have a couple of items that require the sesion to be present for marketing and some price calculations, but the error message I get back from WorldPay seems to indicate that a session variable is not being populated (although the code is obviously getting hit).
Not that I think this has any bearing on it,but here is the offending code:
The bold line is where it is failing with the useless message 'Object reference not set to an instance of an object.' (it would help if ASP.Net could actually tell you which object is not set, but there you go). I suspect it is the Session object that is not being instigated, but I don't see why not.
I have another Ucommerce site that does similar things using WorldPay, and this one works. The only difference between the two that on the failing site, the SimpleCampaign is located as a seperate DLL/Project whereas the one that does work, the SimpleCampaign code is within the main project scope. Both systems work fine as a web site (i.e. session items are being correctly created and displayed/used).
Does the session expire when Ucommerce goes out to WorldPay and if so, is there anyway that this could be retained?
For completeness sake I'm posting the solution here.
The issue turned out to be with combination of WorldPay, the use of session, and the way WorldPay handles confirmation pages.
Basically WorldPay insists on presenting a scraped confirmation page under their own URL, which means that the request issued to get the confirm page does not come from the user itself, but rather from WorldPay, which means that information stored in session for the user is not available.
Soren is absolutely correct, and I'd forgotten that I'd posted this on here!
I got round the issue by creating a simple web page that WorldPay scraped. On this page there was a single hyperlink back to the issuing site which when clicked on resumes the session. The only proviso to this is that (a) the requests to WorldPay must remain on the same browser tab and not open in a new window and (b) the user does actually have to return to the issuing site to complete the order process. This could be accomplished with, rather than a link, an automatic redirect after 5 or 10 seconds.
The use of sessions in this case was to load the campaigns into the browser at the start rather than have to hit the database on each page refresh. There was also a currency selection that was placed into session rather than a cookie (as we all know that cookies are now the baddest of bad things in the world and must be banned forever).
This was an exceptional set of circumstances and I would doubt that most users using UCommerce as Soren wrote it would come across this issue. It was also further complicated by the way our live server web bindings were set up which meant the live server was redirecting all external requests from itself (which in effect was the reponse from Ucommerce to WorldPay) back to itself on a https protocol with a failure of the (non-existant) SSl certifcate. Again, I would suspect that most people would not run into this issue, but the resolution is to create a loopback adaptor bound to the external IP address of the server and bind the website to both the internal and external facing IP addresses. Sounds crazy, but that what I had to do.
Session Failure on Callback
I have a site that is using WorldPay as it's paymnet gateway and I have set up Ucommerce to use this pipeline. Everything is fine up to the point where the Checkout pipeline kicks in and I seem to lose my session varibables. I have a couple of items that require the sesion to be present for marketing and some price calculations, but the error message I get back from WorldPay seems to indicate that a session variable is not being populated (although the code is obviously getting hit).
Not that I think this has any bearing on it,but here is the offending code:
List<SimpleCampaign> Campaigns = SimpleCampaign.GetCurrentCampaigns();
HttpContext.Current.Session["Campaigns"] = Campaigns;
The bold line is where it is failing with the useless message 'Object reference not set to an instance of an object.' (it would help if ASP.Net could actually tell you which object is not set, but there you go). I suspect it is the Session object that is not being instigated, but I don't see why not.
I have another Ucommerce site that does similar things using WorldPay, and this one works. The only difference between the two that on the failing site, the SimpleCampaign is located as a seperate DLL/Project whereas the one that does work, the SimpleCampaign code is within the main project scope. Both systems work fine as a web site (i.e. session items are being correctly created and displayed/used).
Does the session expire when Ucommerce goes out to WorldPay and if so, is there anyway that this could be retained?
Regards
Iain
For completeness sake I'm posting the solution here.
The issue turned out to be with combination of WorldPay, the use of session, and the way WorldPay handles confirmation pages.
Basically WorldPay insists on presenting a scraped confirmation page under their own URL, which means that the request issued to get the confirm page does not come from the user itself, but rather from WorldPay, which means that information stored in session for the user is not available.
Soren is absolutely correct, and I'd forgotten that I'd posted this on here!
I got round the issue by creating a simple web page that WorldPay scraped. On this page there was a single hyperlink back to the issuing site which when clicked on resumes the session. The only proviso to this is that (a) the requests to WorldPay must remain on the same browser tab and not open in a new window and (b) the user does actually have to return to the issuing site to complete the order process. This could be accomplished with, rather than a link, an automatic redirect after 5 or 10 seconds.
The use of sessions in this case was to load the campaigns into the browser at the start rather than have to hit the database on each page refresh. There was also a currency selection that was placed into session rather than a cookie (as we all know that cookies are now the baddest of bad things in the world and must be banned forever).
This was an exceptional set of circumstances and I would doubt that most users using UCommerce as Soren wrote it would come across this issue. It was also further complicated by the way our live server web bindings were set up which meant the live server was redirecting all external requests from itself (which in effect was the reponse from Ucommerce to WorldPay) back to itself on a https protocol with a failure of the (non-existant) SSl certifcate. Again, I would suspect that most people would not run into this issue, but the resolution is to create a loopback adaptor bound to the external IP address of the server and bind the website to both the internal and external facing IP addresses. Sounds crazy, but that what I had to do.
is working on a reply...