One-Page Checkout [Support Thread]

[lat9]

You're right. I misunderstood.

Actually, now that I am fully testing this, if the gift card field is populated with anything but $0.00 and the order is submitted WITHOUT clicking the "Apply" button, Zencart actually throws an error: Your order's details have changed. Please review the current values and re-submit.

@carlwhat For this to be implemented properly, the checkout submit process would need to ignore that field. This might be more complicated than I initially thought. Does your plugin address this?

It's actually One-Page Checkout's processing that issues that message. That's because the order (upon submittal) contains that GC value, but the previous record of the order didn't. That's to 'protect' the customer (and the store) from any misleading charges.

[dbltoe]

@carlwhat For this to be implemented properly, the checkout submit process would need to ignore that field. This might be more complicated than I initially thought. Does your plugin address this?

Best asked in the support thread for the mod.

That clearing of the credit-card fields, IIRC, was a PCI-compliance-related change. What I will look into is the possibility of clearing only the CVV number field, so that all the information doesn't need to be re-entered.

I have found that the more you leave in the forms, the easier it is for the spammers to try to get their stolen cards to work. With just the CVV, all they need do is 999 checks (9,999 for AE) to see which one works. The Zip would be 99,999 which is still doable for the hacker. Turn both off and they will probably bother someone else. And, they will spread the word that you have created a testing ground.

It's always a delicate balance between convenience and security.

[niccol]

I am not sure whether this is alterations I have made or if it is a bug. Still looking at it. Maybe someone can advise me :-)
The file I am looking at is modules/pages/checkout_one_confirmation/header_php.php

Line 203 reads:

                        $_SESSION['shipping']['extras'] = (isset($quote[0]['extras'])) ? $quote[0]['extras'] : '';

The problem is that for a shipping module that has not previously set 'extras' it adds a empty field to the session. Not a problem by itself but then later on we get to ln 278 or so:

$session_end_hash = $checkout_one->hashSession($currencies->format ($order->info['total']));
if ($confirmation_required === false && $order_confirmed === true && $session_end_hash !== $session_start_hash) {
    $error = true;
    $messageStack->add_session('checkout_payment', ERROR_NOJS_ORDER_CHANGED, 'error');
}

Because the session has been amended the error is added. Nothing has actually changed but the hash values will not match.

I find that this is a better version of the line:

                        if(isset($quote[0]['extras'])) $_SESSION['shipping']['extras'] = $quote[0]['extras'];

Perhaps I am missing something though? Or perhaps it is due to a fairly highly modified store. If one of the experts can chime in then that would be great.

Nick

[lat9]

OPC's observer class (which performs the session-hash) doesn't include $_SESSION['shipping']['extras'] as being pertinent to the hash.

[niccol]

OPC's observer class (which performs the session-hash) doesn't include $_SESSION['shipping']['extras'] as being pertinent to the hash.

True.

I had read that file but somehow missed the first lines of the function. What a numpty.

[lat9]

True.

I had read that file but somehow missed the first lines of the function. What a numpty.

Not a numpty! There are a lot of "moving parts" in One-Page Checkout and it's easy to miss some of the intricacies. I had to review back into the code to find that myself.

[mc12345678]

OPC's observer class (which performs the session-hash) doesn't include $_SESSION['shipping']['extras'] as being pertinent to the hash.

But if the condition was understood correctly, on the initial run through of the hash, wasn't $_SESSION['shipping'] not set to begin with? Thus the first cycle would not have that session variable and then when checking for the change, the extras key would be removed but now the shipping session variable would be present?

I say that because of the fix that appeared to work for the OP.

[lat9]

But if the condition was understood correctly, on the initial run through of the hash, wasn't $_SESSION['shipping'] not set to begin with? Thus the first cycle would not have that session variable and then when checking for the change, the extras key would be removed but now the shipping session variable would be present?

I say that because of the fix that appeared to work for the OP.

OPC's AJAX handler sets the session-based shipping. If the overall value isn't set, there'd be a redirect back to the main page prior to the hash.

[njcyx]

I did some tests on the order lookup page (order_status) from OPC. I noticed that, sometimes it will show some errors.

Here are what I found:

In Chrome, open a new Incognito Windows, enter order_status URL directly (/index.php?main_page=order_status). Enter something in order number and email (no matter they are valid or not). Then click "Continue" button. It will always show "Whoops! Your session has expired./Login Time Out". This error page will be shown up by 100% chances.

Then, if I use Go Back button on the browser to go back, enter something in the order number and email then continue, "Whoops! Your session has expired." error page will be shown up again.

Then, under the same windows, if I reload the page or manually enter order_status page URL directly (/index.php?main_page=order_status). Then enter a valid order number and email, click "Continue", you will see the order details. Then if you click Go Back button on your browser, there is a chance that it will show "Confirm Form Resubmission" error. Error code is ERR_CACHE_MISS. If error message is not shown up, click Go Forward button on the browser and you will see the error.

The bottom line is, it seems to me that for order_status function needs to use Cookies or session based. If it is the customer's first time to visit this order_status page (like using a new computer), it will show expired session error. Also it is not advised to use Go Back, Go Forward buttons from the browser during this page, because sometimes it will show ERR_CACHE_MISS error.

[lat9]

I did some tests on the order lookup page (order_status) from OPC. I noticed that, sometimes it will show some errors.

Here are what I found:

In Chrome, open a new Incognito Windows, enter order_status URL directly (/index.php?main_page=order_status). Enter something in order number and email (no matter they are valid or not). Then click "Continue" button. It will always show "Whoops! Your session has expired./Login Time Out". This error page will be shown up by 100% chances.

Then, if I use Go Back button on the browser to go back, enter something in the order number and email then continue, "Whoops! Your session has expired." error page will be shown up again.

Then, under the same windows, if I reload the page or manually enter order_status page URL directly (/index.php?main_page=order_status). Then enter a valid order number and email, click "Continue", you will see the order details. Then if you click Go Back button on your browser, there is a chance that it will show "Confirm Form Resubmission" error. Error code is ERR_CACHE_MISS. If error message is not shown up, click Go Forward button on the browser and you will see the error.

The bottom line is, it seems to me that for order_status function needs to use Cookies or session based. If it is the customer's first time to visit this order_status page (like using a new computer), it will show expired session error. Also it is not advised to use Go Back, Go Forward buttons from the browser during this page, because sometimes it will show ERR_CACHE_MISS error.

I've tried to reproduce on my demo site, but I'm not seeing the issue.