[Authorize.Net - Accept Hosted]

Back again to this extension.  A new issue has popped up that isn't a problem with the extension per se, but some updates would help to mitigate the issue.  Card testing is a recent problem where a bad actor gets tens of thousands of stolen card numbers and uses the accept hosted window in CC to test them.  Once they get the window open, they can do over 10 submissions per second.  All of them are on a single order with the same order number and amount.  Technically, they are hammering on Authorize.net's site and not the server hosting the CC store.  However, this results in both Authorize.net and the merchant processor shutting down the gateway.  I use AFDS on authorize.net but we really need to try to stop the submissions in the first place.

To help mitigate this, I have modified the hard-coded parameters sent in the Accept Hosted extension gateway.class.php file to this:

 {
				  "settingName": "hostedPaymentPaymentOptions",
				  "settingValue": "{\"cardCodeRequired\": true, \"showCreditCard\": true, \"showBankAccount\": '.$showBankAccount.'}"
				}, {
				  "settingName": "hostedPaymentSecurityOptions",
				  "settingValue": "{\"captcha\": true}"
				}

Requiring the card code and ESPECIALLY showing captcha on the submission form seems to stop them in their tracks.  Unfortunately, I have to go in and redo this mod every time there is a new version of this extension since they are hard coded and not part of the variables stored in the config table.

I think it would be a really helpful mod to this extension to make these selectable in the extension admin, perhaps with a simple checkbox like with a couple of the other parameters there.

Thanks for considering this.

[Upgrading from CentOS to Alma Linux]

I upgraded my server to Alma Linux quite awhile ago and had absolutely no issue with CubeCart or anything else on any of my client's sites.  I doubt you will notice any change at all.  It is basically the same as CentOS, except it is being maintained.  

It reminds me of the switch from mysql to Mariadb back when Oracle took over and decided to be dicks about licensing mysql.  No issues at all with Mariadb either.

[Is CC 6.4.10 compatible on php 8.2?]

26 minutes ago, bsmither said:

Please remind me if there is a conversation about this.

No, it's just one of the things I saw when I tested 6.4.7 with PHP 8.2. so I just mentioned it in case it hadn't been discovered in your testing.

[Is CC 6.4.10 compatible on php 8.2?]

Thanks Brian.  I would guess you already found this issue that was present in CC6.4.7 on PHP 8.2: Customer login technically works but just sits on the login page after submit so the user doesn't think they are logged in.  Probably old news to you.

So many little things that have been made much more strict on PHP 8.2 it is making me crazy doing testing / rewriting on my own systems.  No more loosey-goosey coding and running functions like trim (and others) on foreach loops where there may not be data in some iterations.  Lots of other things too. 

I tell you the #[\AllowDynamicProperties] trick is saving me right now because I can run 8.2 while I rewrite hundreds of class scripts to conform.  I realize how lazy my OO coding has been over the years and am paying for it now.

Tighter requirements make us tighter coders, I guess...

[Is CC 6.4.10 compatible on php 8.2?]

3 hours ago, Janet Parker said:

It's best to consult the official documentation or contact the support team of the eCommerce platform you are using, as they would be able to provide specific information about compatibility with PHP 8.2.

I guess I wasn't too clear.  I develop and host data management systems primarily but also have a few clients who are doing eCommerce using CubeCart on my server.  I am finishing up re-coding and testing my systems with php 8.2 and will be switching the last data systems domains to 8.2 shortly.  All of my other clients are moved to php 8.2 already.  My CubeCart sites will be the only 8.1 users on my server.  I would like to move them to 8.2 so I can remove all other php versions.

3 hours ago, Janet Parker said:

However, according to the official release notes of CubeCart 6.4.10, there is no mention of compatibility with PHP 8.2. Therefore, it's possible that CubeCart 6.4.10 may not be fully compatible with PHP 8.2, and some issues may still occur.

Yes, that is why I posted in the CubeCart forum to see if someone like Brian had any additional info.  It would be nice if php version compatibility was part of the documentation of each CC version update.

3 hours ago, Janet Parker said:

It's recommended to test the upgrade on a staging or development environment before performing the upgrade on a production site. Additionally, it's always best to ensure that your site and its components are fully compatible before making any upgrades to avoid any issues or downtime. 

I tested 6.4.7 and know that doesn't work so before I go to the trouble of doing a bunch of testing on 6.4.10, I wanted to post here to see if anyone like Brian knew if it would work or not.  Mostly if they already knew it wouldn't work so I wouldn't waste a bunch of time testing something that was already known to not work.

[Is CC 6.4.10 compatible on php 8.2?]

I have been updating my own data systems to be compatible with php 8.2 and also moving my clients sites that aren't using CC (non-eCommerce clients) to 8.2.

I have my CC stores at 6.4.7 and tested one with php 8.2 and it had some significant issues that made it a no-go.  I will be updating stores to 6.4.10 shortly and wanted to know if this latest version is php 8.2 compatible.

[CC and php 8.1]

1 hour ago, bsmither said:

I would NOT apply the diff file to the filediff program. Guaranteed to result in a hot mess.

 

 

No no.  I have notes of what files have been changed in the skin.  I will run DiffMerge on each of them and carefully update the code on the new CC version skin.  I have very clear remarks on every change.  I just need to carefully examine the code between the old and new to make sure I understand any changes in the new that may affect my modifications.  It is slow and tedious.  And, as I said, I have to think.  Hate that.

[CC and php 8.1]

Thanks Brian.  I have a filediff program.  I was just wondering if I needed to go through it file by file.  Just lazy but since things are pretty significantly re-arranged on my Foundation skin variant, I have to sit and transpose the differences instead of viewing the difference pages and approving the automatic code block updates left to right in the file diff edit window.

I hate it when I have to actually do some work.  Even worse when that work requires me to think.  Thinking is hard.

[CC and php 8.1]

Just wanted to pop back in and thank Brian and Al (and whomever else worked on the update) for the php 8.1 compatibility.  Finally got a rare minute to jump over and do some store upgrades and then switch them to php 8.1.

As always, your work is very much appreciated.

One question - Do you know if anything changed in the Foundation skin between 6.4.4 and 6.4.7?  I have a skin that is based on Foundation but is significantly altered in its element arrangement so I would like to not rebuild it if there is no reason to.

Thanks

 

[Coupon limit per customer apparently counting before checking]

Quote

The problem here is that the query does not specify which coupon is being searched for. Thus, if the customer has used any coupon previously, there will be a record of it - a false positive of testing for this specific coupon used by this specific customer.

Thanks so much for finding that Brian.  Definitely a silly oversight in the code.  Your fix seems to have solved the issue.  This is certainly a bug that needs to be fixed.  Will you be reporting it or would you prefer I do it?

As always, your thorough work and prompt solutions are greatly appreciated. 

[Coupon limit per customer apparently counting before checking]

Yes.  The owner and I both have accounts on his store so we can simulate purchase and checkout.  It did the same thing for both of us when we were logged in.  Out of curiosity, would that make a difference?  I thought that CC tracked customers by email address, whether they have an account and are signed in or not.  I assume that would be relational to the coupon uses counting.

[Coupon limit per customer apparently counting before checking]

Thanks Brian, really appreciate it.

[Coupon limit per customer apparently counting before checking]

Quote

In the table CubeCart_customer_coupon, are there any rows where the value in the 'customer_id' column is zero?

No.  In phpMyAdmin sorting by customer_id shows the lowest number to be 130.  No zero values in that column.

Quote

Are there any other rows that have the same 'coupon' value? 

Not sure I understand this one.  There are hundreds of rows with the same coupon code as he has had hundreds of customers use coupons over the years.  Do you mean if the first test found a zero?  If so, this test is moot, I suppose.

[Coupon limit per customer apparently counting before checking]

Sorry, I normally always post that info but was rushing out the door when I typed it and completely forgot.

"There is never enough time to do it right, but there is always enough time to do it over.” ~John W. Bergman

PHP 7.4, CC 6.4.4

[Coupon limit per customer apparently counting before checking]

A customer put in a coupon code with global unlimited uses and one use per customer.  When used the first time, it displays an error message that the limit has been reached even though this is the first use.  If you set it to 2 uses per customer, it works on the first use and not the second.  Leave it blank for unlimited per customer and it works fine too.  This would make it appear that the code logic is counting the use BEFORE checking if the limit has been reached.  It sounds kind of silly for a mistake like that to be in the code flow, but testing sure makes it seem that way.

Anyone else see this?

[tax rounding incorrectly]

Thanks Brian for confirming my suspicion that there was individual item cascade rounding going on instead of sum subtotal rounding.  I am pretty sure in the U.S. that the tax is always applied to a taxable subtotal.  Even if there are exempt items in a purchase, they are just supposed to be excluded from the subtotal taxability (sort of a ghost subtotal for tax calculation).  A penny isn't a huge deal, but his problem is it doesn't square up with his accounting books and for his state tax reporting.  Technically, he is illegally charging too much tax when this anomaly occurs.  While no one thinks he is looking at jail time for a few cents here and there, it is wrong, at least in this country and / or state.  

It would be interesting to know if this is a response to UK or EU tax codes.  If not, then it is a flawed process that has yielded this issue.  Alas, it appears I will have to go back to him, shrug my shoulders and tell him not much I can do at this point.

Appreciate your help sir, as always.

[tax rounding incorrectly]

OK, so I guess nobody cares about this bug...

[tax rounding incorrectly]

A client in California has noticed that occasionally the tax is rounded to the wrong penny.  As illustrated below, his tax rate is a flat 9% and the total of $140.04 at 9% would be .09 x 140.04 = 12.6036.  This should round DOWN to $12.60.  However, CC 6.4.4 is rounding it UP to $12.61.  My wild guess is that there is other rounding taking place upstream that is delivering something above 12.605 to the final tax rounding or something like that but I really have no idea.

Has this been seen before?

[CC and php 8.1]

My guess: Boooooom!  

Really, you don't have to go through all that.  I don't want to hack CC just because I am a type A PITA.  I can wait for everything to catch up in a future release... I swear I can...  Really... ahhhhhhhhhhhh!

[CC and php 8.1]

That would be very generous of you to do.  PHP 8 has only been out since the very end of November 2020, so that's just under 18 months.  Lots of changes and depreciated / removed functions and conventions so it will understandably take a while for everyone to clean their code.   

All my stuff works fine on 7.4 too, I just am a bit impatient to work with some of the 8.1 improvements.  I have it installed in my MAMP Pro testing server and develop only with that to future-proof as far out as possible so it is important that I have it on my production server, which I do for the domains I use.

For CC, I can just leave it on 7.4 until all is ready and then I will clean 7.4 off the server.

As always, thanks for your help and response Brian.  It is greatly appreciated.

[CC and php 8.1]

Thanks Brian. 

Do you know if Smarty 4 in CC645?  Obviously, if a single third-party component isn't compatible, then the whole thing isn't.

I run PHP as a PFM Application per domain so I will keep 7.4 for the CC clients and wait for the plugins to catch up if they haven't yet.

It would be great if Al specifically announces when the CC version is released that is tested compatible with PHP 8.1.  (wink, wink, nudge, nudge)..

[CC and php 8.1]

Searched around and didn't see much about CC compatibility with the latest php version 8.1.  Just a single post back in 2021 or so about problems with php 8.0 breaking CC.  What's happening with CC and php 8.1?  I am using CC 6.4.4 with php 7.4 right now (CC still recommends using php 7.3, which is now outdated), but all my data systems and some client wordpress sites are moved to php 8.1.  CC is the only thing hanging me up from having 8.1 as the only php version on my server.

Any info on a timeline for this would be greatly appreciated.

[Authorize.Net - Accept Hosted]

Al -

Just noticed that the First Name and Last Name  are inverted in versions 1.0.4 & 1.0.5 on lines 179 & 180 in gateway.class.php

[Authorize.Net - Accept Hosted]

Here is what I have from tonight's test:

- Order DOES go to "processing" even if the customer bails out after hitting the "Pay" button and doesn't go back to the store by clicking the "Confirm" button on the Auth.net results window.  This is great.

- Created a copy of the "Default emails" template, called it "Hard-coded emails", replaced the header image and signature macros with hard-coded urls and made it the default.

- Under the "Email Contents" tab, I modified Cart: Order Confirmed and Admin: Order Received, replacing the macro {$DATA.link} with a hybrid hard-code / macro combination of https://mystore.com/index.php?_a=vieworder&cart_order_id={$DATA.cart_order_id} (where mystore.com is the actual store domain and the order number is handled by the dynamic macro {$DATA.cart_order_id}).

- Have NOT been able to solve the gigantic store title issue on the Auth.net transaction results page.  Will have to keep looking or call their support and find out how to get this under control.

It looks like all of the information is being sent correctly and the transaction was successful. (NOTE: I only tested auth only since my clients all capture funds when the item ships.).

Generally, it works with a few workarounds and the need for a small formatting tweak.  I much prefer the new embedded frame and the clean form look and operation to the old SIM.  It works well enough for me to put it live in one of my client's stores.  We will see how it goes over the next 24 hours of live use.

[Authorize.Net - Accept Hosted]

8 hours ago, Al Brookbanks said:

The silent post url should be triggered before the button is clicked anyway? Maybe I'm wrong. 

Or maybe you are right.  It happened when I first tested this extension but there were other things misfiring so that could have been it. I know the old SIM extension did that but we didn't employ the silent post URL with that.  I will check v4 overnight (HST) and look at the status in admin before I click the CONFIRM button.

8 hours ago, Al Brookbanks said:

anything in the documentation that looks like it can do that seems to break the request to build the iframe URL

Seems to be the standard M.O. with their API and documentation.  Lots of blanks you have to fill in yourself.

One other thing - Do you know if it is possible to format this?

"settingName": "hostedPaymentOrderOptions",
"settingValue": "{\"show\": true, \"merchantName\": \"'.addslashes($GLOBALS['config']->get('config', 'store_name')).'\"}"

The store name is HUGE.  I have searched around the Auth.net docs and I don't see it.  If the store name is a moderately long word, it word-breaks and wraps.  It looks pretty terrible.