Jump to content

Store Settings not saving - goes to store home instead of admin


jasehead

Recommended Posts

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.

Link to comment
Share on other sites

The document part of the URL that CubeCart uses for administration comes from the /includes/global.inc.php file. The URL will be something like www.mystore.com/admin_sTuVwX.php where admin_sTuVwX.php is the "document" the web server must find in order to give it to PHP.

Also, look at the 404 ErrorDocument statement in .htaccess. It says to deliver index.php for any document that the web server cannot find (or successfully rewrite).

Therefore, it stands to reason that somewhere, CubeCart is getting the name of the administration script from somewhere other than /includes/global.inc.php, but the actual administration PHP script is not named that.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Here is the ErrorDocument part of .htaccess for CubeCart 6.1+:

### Default store 404 page ###
ErrorDocument 404 /index.php

## Override default 404 error document for missing page resources ##
<FilesMatch "\.(gif|jpe?g|png|ico|css|js|svg)$">
  ErrorDocument 404 "<html></html>
</FilesMatch>

The first 404 is for when the rewriter fails and there is no document by the name requested. It sends /index.php.

The second 404 is so that nothing is sent back - other than the status code - for missing images, javascript, css files, etc).

If you want to hack the general config settings, then you need to have phpMyAdmin show the Base64 Decoded value. I don't use phpMyAdmin all that much, but I understand there to be a drop-down selector decoder/encoder for cells containing this type of data. You will want to explore the value in the "array" column of the CubeCart_config table, where "config" is the value in the "name" column.

The "name" column is UNIQUE, but not PRIMARY as you found out. If you have two rows for "config", "Free_Shipping", and "Print_Order_Form", then that column cannot be UNIQUE (or PRIMARY). I would think that this database has some discrepancies with respect to what a CC6114 schema should be.

Removing one of the duplicated rows may be easy or not so easy. What you can do is add another column to the CubeCart_config table named "config_id", make it PRIMARY AUTOINCREMENT, and Save. Remove one of each pair of duplicated rows. Then make "name" UNIQUE.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Please confirm if there is, or is not, a UNIQUE index (key) on the "name" column. If there is, then remove it. (I say there cannot be this UNIQUE index, because there being two rows with the same value has already violated that schema restriction.)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.
Edited by jasehead
Link to comment
Share on other sites

Good to see these results.

I cannot speak to mod_security (start up a conversation with a pro web-hosting provider for that), but I should add this to my litany of questions to ask when someone makes a forum post: "It don't work!"

"Has your host installed some sort of security package on your site?"

As for "no telling what legitimate text is going to base64 encode into banned words," there are only two (as far as I can tell) instances where base64 encoded values are used: in SQL queries reading from and writing to the database (CubeCart_config and (for some versions of CubeCart) CubeCart_code_snippet tables), and when POSTing Code Snippet code (for some versions of CubeCart - admin, Manage Hooks, Code Snippets tab).

(As I see it) So, for CC6114, the Code Snippet code text edit area in the admin skin template, no longer converts the textarea contents to base64 so that it survives the POSTing.

I am concluding, therefore, that "attempts to hide badness in base64 encoded strings" is not exactly what is happening here.

Edited by bsmither
Link to comment
Share on other sites

mod_security can on a few occasions throw false positives but with modern, well coded software this almost never happens and the benefits far outweigh these small niggles.  base64 encoded strings do not cause problems generally with mod_security or we would have hundreds of CubeCart sites tripping rules all of the time

Ian

Link to comment
Share on other sites

  • 2 weeks later...

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.

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...