Getting 403 errors from admin/config when trying to build a staging system.

[ploughguy]

Greetings Cubecarters!

I am currently running a 4.3.4 store in production.  I have ambitions to update it, even though it's only been in operation for 14 years, to the latest version available when I finally get to do it.

Part of the process, of course, is to build a test platform so I can see what is going to happen to the live store on The Big Day, should it ever come.

I have taken a copy of the store code and database, dropped them into a new domain, cussed a little, bent a few things into shape, and it mostly works.  I ran though an acceptance test script I cooked up to confirim that the copy process had succeeded, and I can create an order, for example, as a customer, and see it as an administrator.  So a lot of stuff is working.

The only problem I have found so far is that when i try to change settings, I get a 403 error.

I have checked a mess of permissions - the code (admin/sources/settings/index.inc.php) mumbles about creating or updating .htaccess files but the live store doesn't have them, so I don't think it is failing here.  Any thoughts?

Russ

[Theodore2]

If you are getting 403 errors from admin/config when trying to build a staging system, there could be several reasons for this issue. Here are some possible solutions based on the search results:

1. Check the file permissions: The 403 error could be caused by incorrect file permissions. Make sure that the files and folders have the correct permissions. You can use the cPanel File Manager to check the file permissions
   .  KMFusa Login 
2. Check the .htaccess file: The 403 error could be caused by a corrupt .htaccess file. Try renaming the .htaccess file to something else and see if the error goes away. If it does, then the .htaccess file was the cause of the error
   .
3. Check the security plugins: The 403 error could be caused by poorly-configured security plugins. Try disabling the security plugins and see if the error goes away. If it does, then the security plugins were the cause of the error
   .
4. Check the server settings: The 403 error could be caused by incorrect server settings. Check with your hosting provider to see if there are any server settings that need to be changed
    
5. Check the .htaccess file for the admin folder: The 403 error could be caused by a misconfigured .htaccess file for the admin folder. Try removing the .htaccess file from the admin folder and see if the error goes away
    

It is important to note that the 403 error can be caused by a variety of factors, and the solutions may vary depending on the specific cause of the error. Therefore, it may be helpful to review the Drupal documentation and other resources to ensure that you are using the system correctly and that it is the right fit for your website needs

Edited September 8, 2023 by Theodore2

[robertbell]

On 9/5/2023 at 5:16 AM, ploughguy said:

Greetings Cubecarters!

I am currently running a 4.3.4 store in production.  I have ambitions to update it, even though it's only been in operation for 14 years, to the latest version available when I finally get to do it.

Part of the process, of course, is to build a test platform so I can see what is going to happen to the live store on The Big Day, should it ever come.

I have taken a copy of the store code and database, dropped them into a new domain, cussed a little, bent a few things into shape, and it mostly works.  I ran though an acceptance test script I cooked up to confirim that the copy process had succeeded, and I can create an order, for example, as a customer, and see it as an administrator.  So a lot of stuff is working.

The only problem I have found so far is that when i try to change settings, I get a 403 error.

I have checked a mess of permissions - the code (admin/sources/settings/index.inc.php) mumbles about creating or updating .htaccess files but the live store doesn't have them, so I don't think it is failing here.  Any thoughts?

Russ

 

AFIK, since admin/sources/settings/index.inc.php talks about appending rewrite rules to .htaccess and fails if the file does not exist, you probably have a .htaccess file in the live store. Many ftp programs do not show dotfiles by default. Are you sure you have toggled it on?

[Russ]

Theodore, Robert,

Thank you both for your help. I will apply your suggestions and report back.

Russ

[ploughguy]

Yes, yes, yes, yes, yes ... Noooooo.

It got better.  I took methodical approach of adding "die()" statements, first after the .htadmin initialization and rewrite file code (not the culprit, apparently) and then at various points throughout using the good old binary chop.  At some point half my brain went to sleep and I stopped checking if the problem was still there, and eventually, when I had binarily chopped away to nothing, the config update succeeded.  Ummm - dunno.

I want to create another one (a reference system, so I have one which is "before", one which is upgraded to "after" which becomes the pre-production system, and the live system.  I'll update if the problem reoccurs when I build the second copy.

Thanks again for your advice,

Russ

[jakepitt]

When encountering 403 errors from admin/config while trying to build a staging system in Drupal, there are several potential causes. One common issue is related to permissions and access settings. It's important to ensure that the user roles and permissions are correctly configured to access the admin/config area.

Additionally, issues with clean URLs, server configurations, and file permissions can also lead to 403 errors. You may need to check the server logs and Drupal error logs for more specific information on the cause of the 403 errors of kmfusa.

If the issue persists, you may want to refer to community discussions and support forums for troubleshooting steps and potential solutions.