X-Cart 4.5.5 released

carpeperdiem · #**181** 03-02-2013, 11:45 AM

Stumbled into this:
http://forum.x-cart.com/showpost.php?p=350713&postcount=20

Vladimir Gritsenko announced on 10-Dec-2012 that he was going to lock down 4.5.5 --

If you read the entire thread, it is not clear that x-cart had anything to do with the exploits. It sounds like sloppy server administration and sloppy xcart passwords and no plan to lock the admin down. It also sounds like a FTP or other vulnerability at the server(s).

SO -- because some users were sloppy and didn't have a well secured server, "hey, yeah, that's it -- let's put all of that crap into x-cart." The xcart so-called security issues has more to do with crappy and inferior server hosting and inexperienced admins.

So, at the expense of everyone else, they slapped whitewash security on the cart. And destroyed some very useful functions that worked just fine. And the stores with crappy hosting continue to be vulnerable. And those of us with quality hosting and a secure environment have lost functionality.

Instead of telling the server admins to fix the hole in the wall, xcart gave the occupant a face lift. We now have a prettier and well armed (but now partially disabled) occupant and the wall still is insecure.

Are we better off for this?

ADDISON · #**182** 03-02-2013, 12:07 PM

You're continuing the saga without seeing the main problem of XC - upgrading process and how we can improve it. Am I gonna read such of posts every time a new version is out? No folks, we have to cut the bad things once and for all.

Believe me your complains should be followed by solutions. Did you read my advice? No, you continue you own way, waiting for Jesus to bring the best shopping cart. We are the only one doing XC better. If not, it is time to switch the platform with no heart feelings.

NuAlpha · #**183** 03-04-2013, 01:48 PM

Have any of these upgrade issues actually been resolved? I apologize, but I had a hard time following this post to tell what was *actually* fixed.

We're at 4.4.5 and before we go through a lengthy complicated upgrade of the DB and then the code, I want to make sure the upgrade won't just be stalled out. Or worse, that we and our customers won't be locked out because of password problems.

carpeperdiem · #**184** 03-04-2013, 07:47 PM

I walked away (for now)

kustomrides · #**185** 03-04-2013, 09:06 PM

I learned long ago that fewer companies beta test their upgrades. X-cart is one of those. I've even found that Apple's iOS upgrades have fallen to this.

Rule One in software upgrades: ALWAYS back up. Back up on your server and back up on your own hardware. Back that up, too, just in case. Ounce of prevention here. So if you must upgrade on a live store, be ready to trash the upgrade and re-install.

Oh, and one more thing: WAIT on a new upgrade so you can read threads like this. Let others beta test for you, so you can decide whether to even touch the darn upgrade. (I'll take a pass on 4.5.5, thank you.)

cflsystems · #**186** 03-04-2013, 10:45 PM

Quote:

Originally Posted by kustomrides

... WAIT on a new upgrade so you can read threads like this. Let others beta test for you...

If everybody waits on others the software will never get tested

kevinrm · #**187** 03-04-2013, 11:42 PM

My 4.5.5 is working pretty good right now, so there is light at the end of the tunnel...

aim · #**188** 03-05-2013, 01:46 AM

I have re-uploaded the upgrade packs for X-Cart 4.5.5 with the following improvements:
-Optimization of the upgrade process for stores with Social login installed;
-Small improvement related to the first hunk in tpl files to reduce 'Could not patch' problems.

Carzilla · #**189** 03-05-2013, 02:42 AM

Is there a way to force post_patch.php again? I have upgraded my webshop to 4.5.5, but due to the errors the customers passwords haven't been upgraded. I'd hate to have to mail them all for a new password. I know post_patch.php is responsible for the password but it seems it needs to be run within a certain context.

ADDISON · #**190** 03-06-2013, 01:49 AM

>>> THIS IS A SEROUS SECURITY BUG

1. I would like to register a new customer account in Front-End. It has the same email address as the administrator.

2. I fill in the registration form and X-Cart already inserting all data I supply in the registration form inside the DB (I checked with phpMyAdmin) without any restriction.

3. Later after that X-Cart shows a message with red color "Email address already exists in address book". But looking inside the DB data I already supplied are there, recorded as a new row.

*** HERE COMES THE PART I LIKE ***

4. Let's fill in again the registration form for a new customer (the one registered before is logout). NOTE: I will use the same email address from step 1.

ASTONISHING, XC REGISTERS A NEW ROW INSIDE THE DATABASE !!!! THIS IS AN EASY WAY TO SET UP LOTS OF RECORD IN THIS TABLE, OR TO DESTROY OTHER ACCOUNTS!!!

This is a serious bug in my opinion. You should check the email address or other fields before adding them to DB in [xcart_customers] table. Adding a new row in this table should be made after the process is done successfully.

>>> SEE THE IMAGE - 4 accounts with the same information (email, password, ...)