jasehead Posted November 1, 2018 Share Posted November 1, 2018 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 More sharing options...
Noodleman Posted November 1, 2018 Share Posted November 1, 2018 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 More sharing options...
jasehead Posted November 1, 2018 Author Share Posted November 1, 2018 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 More sharing options...
Noodleman Posted November 1, 2018 Share Posted November 1, 2018 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 More sharing options...
bsmither Posted November 1, 2018 Share Posted November 1, 2018 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 More sharing options...
havenswift-hosting Posted November 1, 2018 Share Posted November 1, 2018 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 More sharing options...
jasehead Posted November 2, 2018 Author Share Posted November 2, 2018 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 More sharing options...
jasehead Posted January 5, 2019 Author Share Posted January 5, 2019 Still a problem. Not fixed. Link to comment Share on other sites More sharing options...
havenswift-hosting Posted January 5, 2019 Share Posted January 5, 2019 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 More sharing options...
keat Posted January 8, 2019 Share Posted January 8, 2019 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 More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.