Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

jasehead's Achievements


Newbie (1/14)

  • Dedicated Rare
  • Week One Done
  • One Month Later Rare
  • One Year In Rare

Recent Badges



  1. I'm having some issues upgrading. What I'm wanting to do is to create a test upgrade of the store in a different folder. The issue now is that links in the new store seem to be redirecting to the old one. So if my old store is BOB and my test upgrade is HENRY, every time I click something in HENRY (like a product or menu) then it redirects and I'm back to BOB again. And if I do force the address to HENRY then I get a 404 not found error. The admin side is working fine in HENRY and is reading from the HENRY database OK, so I'm not sure what's going on. Nevermind - worked out that .htaccess needed edits for the base and 404 lines.
  2. Is anyone using this successfully? Does anyone have advice or experience with this? How useful is it? What exactly does it do and not do? Does it help to track sales or just page visits? If it tracks sales, then does it work for all gateways?
  3. store_title, store_meta_description, store_meta_keywords and store_copyright are all encoded into the config. Given that these fields can contain all sorts of store-specific text and code, some stores could occasionally trip mod_security after a server-level Core Rule Set update by the web host. If these fields turn out to be the source and the problem is reported by other stores, then maybe store information that is readily available to Google/customers doesn't need to be base64 encoded in the config array. If this problem turns out to be more widespread, then maybe it's the variables in the array. This was not a problem that I picked up right away, it was a few weeks after the CRS security update when I tried to update store settings (set a storewide discount for a temporary sale). Other stores that don't fiddle with store settings may be affected by a server update but never notice.
  4. Finally resolved by the webhost by whitelisting a mod_security rule to avoid the false positive. My workaround in the meantime was to use .htaccess at the web root to temporarily disable mod_security, make my store settings changes and save as normal, then enable mod_security again: (in .htaccess) ## Remove hash from start of lines below if mod_security is throwing a 403 error, comment out with hashes again when done. # <IfModule mod_security.c> # SecFilterEngine Off # SecFilterScanPOST Off # </IfModule> I think the 403 forbidden/permission error, in this case, did relate to the base64 encoded config array - probably because mod_security detected a word like "ON" within the base64 text ((( OntpO decodes to :{i ))) which was common in the CubeCart_config arrays. Mod_security is probably going to be a recurring problem for some stores because: there's no telling what legitimate text is going to base64 encode into banned words, hosts using mod_security continually update the CRS (Core Rule Set) which may result in new matches/problems, and base64 can be used to hide malicious payloads - so mod_security is focussing more attention on any obfuscated code.
  5. I did try a blanket reset of file and folder permissions - didn't fix the problem.
  6. My webhost runs a suPHP environment. Am I going to cause issues with CubeCart if I blanket reset file permissions to 644 and folders to 755 ? Anything I need to be careful about or make custom changes afterwards?
  7. Still no luck with the webhost. Do you think that encoding the config could be tripping a security rule? There has to be some reason why saving the store settings produces a different result to the other admin tasks.
  8. I exported the database, deleted the duplicate rows from CubeCart_config, dropped all tables then imported the database. I was then able to assign a unique key to the name column and edit the table. Still talking with the webhost trying to sort the mod_security issue. So I decoded the config, made my settings changes, re-encoded it as Base64 and pasted it back - my changes are working OK. I'm going to need to make another settings change later, so I'm hoping to get the 403 permissions error sorted with the webhost by then.
  9. There are no indexes or keys applied to the table - it's just simple.
  10. I've tracked the .htaccess with the 403 redirect to the web root (tested .htaccess files in web root, store folder and admin folder). ErrorDocument 403 https://www.mysite.com.au/store/ Saving changes to the store settings is causing a 403 error. Should I be looking at file permissions or contacting my host about mod_security rules? Can't add a column to the CubeCart_config table - the table cannot be edited because of the duplicated rows. I would expect I'd probably have to export the database, edit the text file and import it back. I think the duplicate rows crept in during multiple CubeCart upgrades over the years.
  11. I had a look at decoding the config with Base64, making changes and pasting into phpMyAdmin - but the config table has config, Free_Shipping and Print_Order_Form twice so I can't assign a unique key to be able to edit the config. I guess I could write a replace in SQL but I'm starting to feel like I'm hacking at this problem with an axe.
  12. Could an apostrophe in the settings be a new issue? It wasn't previously, but checking the staff access log the last "Settings updated" entry was 11 days ago, and that would have been updating 2018 to 2019 in the Search Engine Settings > Meta Keywords. In Settings, we have apostrophes in the store name, meta description and copyright. Unfortunately, I can't remove the apostrophes to test this theory because the store settings won't save.
  13. The admin file and folder are both correct in global.inc.php - I can log into admin OK, view and edit orders, add products, clear cache etc. But trying to save changes to store settings is the problem. I did try commenting out 404 and 403 redirects in .htaccess at the web root and also the store folder but still had the problem. In Admin, .htaccess says: ErrorDocument 404 "<html></html> So I tried commenting that out too - no change.
  14. I'm using cc6.1.14 and trying to make a store settings change in admin, but when I try to save it redirects to the home page of the store instead (not admin). I've tried disabling any 404 or 403 redirects in .htaccess but no luck. I did have a look at the store config settings in phpMyAdmin to see if I could make my small change there but I think the config is locked up with binhex. I'm going to try backing up my Admin folder and reinstalling a vanilla version, but if anyone has any ideas on where to look for what is causing this problem let me know.
  • Create New...