Checkout Review page sending customer back with no message [#2296121]

Hi,

I have a customer who's site has an issue that pops up roughly once every 50 orders or so. Several customers have reported that they get to the Checkout Review screen and when they submit their order they are taken back to the first checkout screen with no system message and all their information is wiped out. This will happen to them every time and isn't something that goes away after a few more tries.

I searched online and have seen this issue scarcely reported before and their reasons reported are not something that would apply to this site or their fixes have already been applied with no success.

This isn't an issue I have ever been able to replicate. I've added some extra watchdogs to Ubercart and I've sort of narrowed the issue down to be that the session variables Ubercart creates disappear. Ubercart has a check where if the session variable doesn't exist it tosses the user back to the first checkout page with no message. I haven't been able to find an area in the code that could potentially wipe out these session variables. I have heard that older browsers have some bugs that are known to make them lose their sessions but I still haven't been able to replicate this through older browsers either. Plus, I have other installations running the same Drupal 7/Ubercart combo that haven't reported this issue ever.

Has anyone else encountered this same problem yet?

Thanks

Comments

Comment #1

TR CreditAttribution: TR commented 1 July 2014 at 22:27

Yes, loss of the session is a likely cause. Make sure you're using https on both pages, as this might be caused when you switch protocol from http to https or vice versa. Closely examine the all the resources (images, css, js, etc.) loaded by the review page, because if some are being loaded through http instead of https (assuming your main page is https) that will cause a problem. There might also be payment issue, since pressing the submit button is when the charge is attempted. If the payment method you're using doesn't report a payment failure or error in the logs or in a system message then you will just see a return to the checkout page.

Comment #2

swickham CreditAttribution: swickham commented 2 July 2014 at 23:47

Thanks for the response.

I actually have the site setup so every page is loaded as https. I've changed all resources to load from an https location only, and if they can't, I removed them. I've also loaded the pages with Firebug's Net tab open so I could confirm all requests from the page are https as well. As far as I can tell it doesn't look like an http/https switch is the issue.

I've noticed that the Submit Order button triggers an ajax callback before it continues on. Do you know what the function name is that the callback is hitting up? At the very least, that function will be a place where I can add some more watchdogs to see at which point the session is dropped.

Thanks

Comment #3

TR CreditAttribution: TR commented 10 July 2014 at 00:04

I don't know of any Ajax involved in the Submit order button. Perhaps you have a contributed module that is doing something here?

Even if all your CSS or JS files are loaded via HTTPS, it's possible they reference images etc. that subsequently get loaded through HTTP. This will break the session.

Comment #4

swickham CreditAttribution: swickham commented 14 July 2014 at 18:18

Okay I've found out what the cause was. The site I was working with has a piece of 3rd party chat software installed which is loaded via a js code snippet. I always made sure the snippet loaded from an https address and that would be the end of it but didn't consider the fact that the actual content it pasts into the DOM may not come from an https source. In this case the chat software loads on single image from an http source.

While I don't have access to their software to change that location to confirm this is the exact issue, it was definitely the chat software since when I removed it the problem disappears. Since the time of starting this thread I found the victim of this issue was some Safari browsers. Apparently Safari has much more paranoid cookie storage than other browsers and this http/https conflict would cause it to dump something that would lose its hold on the session variables.

Thanks for your help TR.