Error when updating database fields: "403 forbidden"

10 posts by 8 authors in: Forums > CMS Builder
Last Post: October 21, 2015   (RSS)

By Damon - March 31, 2015

Hi Harald,

Can you send in a Support Request with your CMSB login and FTP details (don't post those here) so I can take a closer look:
https://www.interactivetools.com/support/email_support_form.php?priority=free

Include the URL to this post in your support request:
http://www.interactivetools.com/forum/forum-posts.php?Error-when-updating-database-fields-403-forbidden-80001

Thanks!

Cheers,
Damon Edis - interactivetools.com

Hire me! Save time by getting our experts to help with your project.
http://www.interactivetools.com/consulting/

By shawn - April 8, 2015

Hi Guys

I'm having a similar issue. When I try update and save a section editor, I get the following "There was an error sending the request! (403 Forbidden)"...

Kindly advise?

By Dave - April 8, 2015

Hi Shawn, 

The likely cause is that your host is running a program called "mod_security" that tries to block malicious web requests, but sometimes gets it wrong and blocks valid ones too.

If you've renamed your admin.php to another name, try renaming it back to admin.php and see if the problem still occurs.  Mod_security doesn't apply as many restrictions to scripts named admin.php.

Next, if that doesn't work, try emailing your host, let them know you're getting 403 errors and ask if could turn off mod_security or any other scripts that may be interfering with your CMS.

Hope that helps, let me know how it goes!

Dave Edis - Senior Developer
interactivetools.com

By JeffC - May 12, 2015

Hi All

I was experiencing the same problem. In my case I wonder of the security only kicks in when x number of requests are made. I updated 10 section editors in quick succession in Chrome without any issues, then received the 403 error. I switched to Safari and updated without any issues. Not sure if this was just coincidence but it might be worth a try before emailing your host. 

Jeff

By gregThomas - May 12, 2015

When I've looked into this issue before, I've often found that the content that is being added when editing/creating a record is what causes the 403 error to trigger. For example if you have a field that contains a domain name or something that could be interpreted as a MySQL statement (eg: "Select item's from above"). 

Cheers,

Greg

Greg Thomas







PHP Programmer - interactivetools.com

By rconring - May 14, 2015

Yes, I had the same problem with Go Daddy hosting.  The problem would occur when I used info1 or info2 as a target URL for an image.  They finally fixed it but I discovered that I could get around it by dropping the http:// it would not trigger the error, so I appended it back to the address on the front end! LOL

Ron Conring
Conring Automation Services
----------------------------------------
Software for Business and Industry Since 1987

By mizrahi - October 15, 2015

Add me to this list. The hosting company (host centric) does have mod_security enabled, and does not allow for it to be disable. I am currently running 2.14 and trying to upgrade to 2.65, but I keep getting the server errors. Glad I made a backup before trying to upgrade :)

Can anyone help out?

By Dave - October 16, 2015

Hi mizrahi, 

Sure, can you do the following: 

  • Install 2.65 in a new directory (keep it separate from your current install)
  • Email me CMS/FTP login details to dave@interactivetools.com (don't post login details to the forum)
  • Send me a link to this thread and steps to recreate the error

I can then isolate a simple test case to recreate the problem and write a message to relay to your host.  

Hope that helps!

Dave Edis - Senior Developer
interactivetools.com

By Dave - October 21, 2015

Hi Mizrahi, 

Thanks for emailing in your server details.  I've got your new install working now.  Can you give it a try and let me know if you run into any other problems?  Here's some details: 

The CMS comes with some default server config files in the /cmsb/ folder named .htaccess, .user.ini, and php.ini. These config files attempt to reset PHP and Apache settings to standard values and turn off deprecated or problematic features that would otherwise cause errors or problems.  These files aren't supported on all servers, but on many they will prevent problems. However, they are optional and you can safely remove these files if needed.

What was happening was our php.ini was overriding the default server php.ini settings and the server had a setting (cgi.force_redirect = 0) that was required by your server but not included in our config file.  This was the cause of the "Internal Server Error" messages.

What I've done to address this is to add this commented section to the php.ini for future releases: 

; EXPERIMENTAL - HOW TO FIX 500 INTERNAL SERVER ERROR (ON CMS INSTALL)
; If you're getting an "Internal Server Error" when INSTALLING the CMS here's what to do:
; 1) Create a temporary phpinfo.php in your website root with this: <?php phpinfo(); ?>
; 2) Because that file is above your cms folder it will show default server settings that are unaffected by the CMS config files (php.ini, .htaccess, and .user.ini)
; 3) View that phpinfo.php in your browser and search for this setting: cgi.force_redirect (it may or may not be found)
; 4) If cgi.force_redirect is found and is set to 0 in the left-most column, uncomment the line below (by removing the ;)
;cgi.force_redirect = 0
; 5) IF THAT DOESN'T WORK: re-comment the line above and try disabling this config file by renaming it to: php.ini.disabled
; 6) Remove temporary phpinfo.php file in website root
; Reference: http://php.net/manual/en/security.cgi-bin.force-redirect.php
; Reference: http://www.hpenterprisesecurity.com/vulncat/en/vulncat/php/php_misconfiguration_cgi_force_redirect.html

And I've added a "Troubleshooting" section to the install documentation that addresses this issue: 
http://www.interactivetools.com/docs/cmsbuilder/install.html#troubleshooting

It works to either disabling php.ini (by renaming it) or adding the setting your server needs.  Ideally we like to use the cmsb config files as they fix several other common issues (like raising low memory limits that prevent image uploads, etc).

Hope that helps, let me know any questions!

Dave Edis - Senior Developer
interactivetools.com