Jump to content

jasehead

Member
  • Content count

    123
  • Joined

  • Last visited

Community Reputation

0 Neutral

1 Follower

Recent Profile Visitors

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

  1. 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.
  2. I did try a blanket reset of file and folder permissions - didn't fix the problem.
  3. 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?
  4. 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.
  5. 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.
  6. There are no indexes or keys applied to the table - it's just simple.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. Replacing the Admin folder didn't solve the problem.
  12. 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.
  13. After searching through code changes and not finding anything: I renamed my custom skin folder by adding a few characters (BOB11) Made a copy of the Foundation folder and renamed it to my original custom skin name (BOB) Replaced the config file in my new skin (BOB) with my old custom skin config (BOB11) Uploaded the new skin (BOB) to my site - so a fresh Foundation skin with my old config After that, I copied back the images, js and css folders - no issues with the site. Then I copied back any changed template files, two or three at a time. Each time I used Admin/Maintenance to clear the cache in Cubecart, then tested on Chrome, Firefox and Safari (clearing browser caches and reloading the page from source). I performed more than 30 tests on multiple browsers before all files were back and couldn't find any problem - a few blank screens at the gateway stage but that seemed to resolve itself after a while. So maybe there was some issue with the original files (done as an upgrade using the setup folder). A fresh upload of the Foundation skin and then adding back the modified files and cleaning the cache seems to have fixed my problem - BTW very similar to this one: https://forums.cubecart.com/topic/52443-register-and-checkout-not-working/
  14. This is happening to me too on 6.1.14 - when a guest customer completes their address details, the Secure Checkout button won't proceed. Also, when a guest tries to register, the Register button won't work. I've tested this with reCAPTCHA off and also v2. I have a heavily modded checkout, but I haven't touched the registration page. I'm thinking that if the registration page is having the same problem then there might be a shared script. I did try the vanilla Foundation skin and everything did work OK - registration was OK, checkout as guest was OK (both with reCAPTCHA v2) - so I'll be comparing my modded version to track down why.
  15. BTW - this site (woocommerce) uses radio buttons for payment gateways at checkout - you may have to add some items to cart for testing then have a look towards the bottom of the checkout page. When you click the radio button a line of text or other information appears underneath to help explain and promote the gateway to the customer - would be great to see that available in Cubecart. There is a Gateway Help option in the Cubecart checkout, but only as a clickable icon and only visible if help is available - never seen it working though.
×