X-Cart forums

[Ene]

please note since the update no users can now register again, which is what happened with the last update too...

Could you please create a new ticket in the HelpDesk regarding this matter?
We will check if this issue is related to the security patch.

[RichieRich]

The message reads: "Please make sure all required fields are filled in" , which they are, missed orders and customers emailing about this simply dumping checkout process

[RichieRich]

SOLVED problem appears to have been username has a . in it, (ie. Username: firstname.lastname)

[KathyHS]

Originally Posted by rubyaryat

Cause of remote file inclusion attack for KathyHS site was webhost had registered globals enabled in php configuration.
Also I advise all users running x-cart to enable suexec if running apache webserver.
Rubyaryat

Thanks for figuring that out, rubyaryat

(and sorry for the other)

[concepts]

We applied the Dec 18th patch and still was hacked via POST commands.

We have since applied the DEC 25th patch and we'll see if they can still get through.

[BritSteve]

Does anyone know whether the line of code that Jon has changed is used for both new registrations and logins? I have changed the code and added '.' as an acceptable character. I looked through our existing usernames, and both periods and @ are used by customers. I need to make sure that customers, both new and existing, are able to use these 2 characters.

Thanks for the mod Jon!

Thanks.

Steve

[beetlejuice]

Well I'm confused that's for sure,

I manage 5 sites all but one running 4.1.9. The other runs 4.1.10.

I jumped the gun (end of year pressure) and didn't check the note re: " for use with 4.1.10 and 4.1.11" For previous versions please make sure you have installed all previous security patches" etc etc.

Went ahead and updated two 4.1.9 sites and they're perfect, the other two wouldn't allow new registrations, previous customers to log back in, nor could admin log in.
(thank god for backups )

After reading more on this forum, it seems as though the security patches quite often create more havoc than what they're meant to protect. The two sites with the problems have a prepare .php file that is so different to the new one supplied in the patch that there is no way of patching the original, I don't believe. As a test I modified all the include and payment files and then overwrote the original prepare.php with the new one from the patch, that just killed the sites stone dead.

So I've logged a ticket with QT and we'll see what they can come up with. I think gb2world's post may be be spot on, Qualteam may have had very different versions of 4.1.9 depending when they were downloaded.

I'll follow up with their response

[gb2world]

It will be interesting to see if QT comments on their process of having different versions of files within a distribution depending upon what date it was downloaded. Seems this has the potential hinder a smooth upgrade process.

I seem to recall that for Lite Commerce - QT developed a tool which did a comparison of the file version (the comments only) of your shop to the latest distribution so you could easily tell which files they had modified since your installation. Something like that for XCART shops would be helpful for this type of required patches.

Since QT probably does a lot of patches and responds to tickets about problems applying them - they would know if this is a concern or not. They may have a way internally of telling when a distribution is up to date with all the latest files.

[bigredseo]

Most distributions by other companies would have an extension on the end of the version number to denote additional changes

Even putting a unix timestamp may be helpful, or just a date:
4.2.0-1230661200 = 12/30/2008 18:20
OR
4.2.0-12302008 or just 4.2.0-1230

Definitely if changes are being made to an archive, that can create serious issues (even from bug tracking point of view.

[gb2world]

Since QT's development & support processes are certified under ISO 9001:2000 Quality Management System Standard - they have to be managing these distributions internally. They may not have evidence that their release process is the cause of our problems with these security patches. Right now - there is no reported solid evidence for that - unless they find this is the issue with Beetlejuice's ticket. I just know based on the problems reported in the forums - I can't apply the patches until I can resolve the differences between the current 4.1.11 distribution and an upgrade pack I used in September. I have to find time to download the current distribution and write a script to compare the version information in each file to my XCART instances.