Chrome - Confirmation Password does not match

[jmelson]

I had this problem on my old store with the Chrome browser, during checkout, the customer gets :
Address Errors - Confirmation password does not match password.

This was a well-known problem several years ago, and the fix recommended to the includes/checkout/checkout.js
file fixed it. But, now, with osCmax 2.5.4, that fix did NOT work. Is there some other location that also needs a patch?

The fix was to replace line 1149 :
if($('assword[name="password"]').val() != '')

with :
if($('assword[name="password"]').is(':visible') && $('assword[name="password"]').val() != '')

(please ignore the stupid emojis above.)

I went over it character by character and don't see any mistake.

Thanks,

Jon

[jmelson]

Well, I installed Chrome here and tried it with Authorize.net -- I was logged in, and entered a test transaction. When I clicked the confirm button on the Authorize.net page, I got back to my web store's login page. So, not the same error, but still did not complete a transaction.

OK, I get the same result with Firefox, too. it goes to the Authorize.net page, I click "pay now" and I go right back to the login page.

(I can't test with PayPal, as they won't let you pay yourself.)

Thanks for any insight.

Jon

[pgmarshall]

Might be a session issue - is it maintaining the session otherwise? Ie. Is your basket persistent?

Regards,

[jmelson]

Might be a session issue - is it maintaining the session otherwise? Ie. Is your basket persistent?

Regards,

I was thinking something along those lines after reading some discussions. Mostly, the basket SEEMS to be persistent, but I did see this morning that items I put in the cart a few days ago suddenly appeared in the basket after one test order. So, this is the osCid issue, right?

Once I'm logged in, should I see &osCid=xxxxx in the url at the top of the browser? (I do see &osCid in some of the apache2/access.log entries.)

Thanks,

Jon

[jmelson]

OK, digging in the logs, when I did a checkout through Authorize.net, using the Chrome browser, I see a bunch of GETs with no osCid, then 6 POSTs to checkout.php. The first 5 POSTs have the osCid, the last one does not have it. Is that significant? This seems to be consistent, with Chrome and Firefox.

Thanks,

Jon

[jmelson]

And, some more info:
I have authorize.net's receipt page set up to POST to ~~~/catalog/checkout_process.php
In the logs, I see these POSTs coming from their server, but WITHOUT an osCid in them. That seems like it has to be the problem. So, when authorizenet_cc_sim.php sends the user over to authorize.net, it needs to put the osCid in the URL it is sending, right?

Thanks,

Jon

[jmelson]

Might be a session issue - is it maintaining the session otherwise? Ie. Is your basket persistent?

Regards,

OK, there definitely seems to be a session issue - I have now seen several times that extra items just APPEAR in somebody's cart, when I am testing with fake customers.

So, I have :
Sessions dir /tmp
Force Cookie Use true
check SSL session ID true
check user agent true
check IP address true
prevent spider sessions true
recreate session true

I've tried several variations of these settings, it didn't seem to make any difference. But, I'll be glad to try some other settings if somebody has an idea.

Thanks,

Jon

[jmelson]

Might be a session issue - is it maintaining the session otherwise? Ie. Is your basket persistent?

Regards,

Oh, wait! I'm testing from the same computer/browser, so any cookies could easily confuse things! So, I think the funny stuff in the basket is due to the "shared" cookies.

Jon

[Markcm]

I had some similar issues as well that were related to cookies. Hopefully clearing them out will help. And [I think] session data is stored to the database, as defined at the bottom of configure.php, not the temp folder even though there is a setting for that from the admin panel.