Jump to content
jasehead

Problem updating product if CASE in product title.

Recommended Posts

This is a recent problem, so I expect it is from some background server update rather than CubeCart.  I'm running CCv6.1.14 because it's been stable and upgrades are a major disruption - so no recent changes at my end.

The problem is that if the product contains CASE in the product title (pencil case, glasses case) then I can not update the product - it just defaults back to the retail storefront (probably caught as a 403 or 404 error by .htaccess and redirected). The only workaround is to make the item one word, eg. pencilcase, which is not ideal.

What I want to be able to do is either:

  • use some mod to make cubecart more robust by making sure the string is being treated as just a string, and not containing SQL commands, or
  • capture the SQL that is generated when a product is updated so I can show this to my webhost support

Any help?

Edited by jasehead

Share this post


Link to post
Share on other sites

this will be because the word "CASE" is a command in an SQL query, so the SQL server may be picking up on this word. however, I can't seem to replicate the issue on my test stores. Try updating to the latest version, I can't replicate it there. seems fixed and probably a former bug

Edited by Noodleman

Share this post


Link to post
Share on other sites

It isn't a bug in 6.1.14 either.  These products were created with 6.1.14 within the last few months (and updated since then with no problem) - only in the last week or so has there been any issue, which is why I think it's due to some background server update.

Upgrading cubecart is not an option because that would cause a major disruption - not looking to spend weeks fixing all the new problems from an upgrade until well after Christmas.

How can I capture the SQL that is generated when a product is updated so I can show this to my webhost support?

Share this post


Link to post
Share on other sites

check the error logs, if it's a failing SQL query I think CubeCart will log the failed query in your version. 

Note, you'll want to consider upgrading sooner rather than later, the version you are on has some major security vulnerabilities

Share this post


Link to post
Share on other sites

I would concur that your hosting provider has implemented (or restored a ruleset to default) a security package on the server hosting your site.

"it just defaults back to the retail storefront (probably caught as a 403 or 404 error by .htaccess and redirected)"

From admin updating a product? What does the URL in the browser's address bar say when displaying the storefront after POSTing the product update? Specifically, does the URL in the address bar include index.php or just simply the domain name?

Have your browser display its developer's panels and view the Network waterfall. It will show the POST, probably with a 301 response code. That response code is CubeCart telling the browser what page to fetch next. The next line is that next page. Please note the response code from the POST.

The admin section does not use seo-friendly URLs that would get rewritten. There is always admin.php (or more likely admin_hAsHeS.php). If the admin script file is missing, then the 404 declaration in the .htaccess file will be triggered because the actual specified admin script filename was not found.

Share this post


Link to post
Share on other sites

A 403 error is often caused by a mod_security rule trip so you will need to speak to your hosting company and find your which rule is being tripped and then take a judgment if you want it whitelisted (which whitelists it for your whole website, not just for you).  Core CubeCart very (very) rarely trips any mod_security rules so it is likely to be some content within that page causing the issue

Share this post


Link to post
Share on other sites

First thing I did was check error logs for SQL errors, but nothing found.  I agree that a mod_security rule update was probably the issue - this has been a problem in the past with my hyper-vigilant web host.  I did some testing today and it seems to have been remedied.

Share this post


Link to post
Share on other sites

Well, you didn’t actually do anything last time as you indicated that it just stopped, so not surprising.

As before, check for mod_security rule trips from your own IP address.  Simple to check and assuming it is this (95% of 403 errors are caused by this) it is easy to prevent it from happening

Ian

Share this post


Link to post
Share on other sites

Id also suggest that this is probably a Mod Security rule on the server.

I took a look inside one of my Cpanels, and it seems that the end user may not have access to disable rules other than to disable MOD Sec entirely, which is not a good idea.

However, to prove if it is indeed MOD-Sec causing the issue, you could try disabling it temporarily in Cpanel (or Plesk )

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×