Jump to content

Problem updating product if CASE in product title.


jasehead

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?

Link to comment
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

Link to comment
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?

Link to comment
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

Link to comment
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.

Link to comment
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

Link to comment
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.

Link to comment
Share on other sites

  • 2 months later...

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

Link to comment
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 )

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...