ccgi down

[#1]

Hi all,
My company's website is also down - we are getting a "403 Access forbidden!" message and the following output in the browser:

You don't have permission to access the requested object. It is either read-protected or not readable by the server.
If you think this is a server error, please contact the webmaster.
We have a .htaccess file with the following contents:
#Options +FollowSymLinks
#RewriteEngine On
RewriteBase /
RewriteRule ^index.htm index.php
RewriteRule ^products.htm products.php
RewriteRule ^content.htm content.php [NE,L]
RewriteRule ^other-services.htm other.php
RewriteRule ^services.htm other.php
RewriteRule ^partners.htm partners.php
RewriteRule ^customers.htm customers.php
RewriteRule ^company.htm company.php [NE,L]
RewriteRule ^contact.htm contact.php
RewriteRule ^accessibility.htm accessibility.php
RewriteRule ^privacy.htm privacy.php
RewriteRule ^(.*)-products-(.*).htm$ products.php?ID=$2&%{QUERY_STRING} [NE,L]
RewriteRule ^(.*)-content-(.*).htm$ content.php?ID=$2&%{QUERY_STRING} [NE,L]
RewriteRule ^(.*)-partners-(.*).htm$ partners.php?ID=$2&%{QUERY_STRING} [NE,L]
RewriteRule ^(.*)-other-(.*).htm$ other.php?ID=$2&%{QUERY_STRING} [NE,L]
RewriteRule ^(.*)-company-(.*).htm$ company.php?ID=$2&%{QUERY_STRING} [NE,L]
Redirect Permanent /solutions http://www.simpcom.co.uk/products.htm?
Redirect Permanent /products http://www.simpcom.co.uk/content.htm?
Redirect Permanent /gr http://www.simpcom.co.uk/partners.htm?
Redirect Permanent /print http://www.simpcom.co.uk/other-services.htm?
Redirect Permanent /consultancy http://www.simpcom.co.uk/other-services.htm?
Redirect Permanent /print http://www.simpcom.co.uk/other-services.htm?
Redirect Permanent /about http://www.simpcom.co.uk/company.htm?
As you can see, I've tried to comment out the first 2 lines to se if this made a difference, but it hasn't. All the permissions are set to 0700 or 0755 for each PHP script. In Dreamweaver and using FireFTP (a Firefox extension), I try to set the permission of the root directory to 0710 but this does not apply.
Can anyone help me with this?
Many thanks,
Anthony

[#2]

Quote from: Tony

the original one ($PHP_SELF) worked OK

Just to clarify (or not) $PHP_SELF doesn't strictly work, but turning register_globals = off kills it, so the html appears as action="" or window.location.replace( "" ), which works but probably shouldn't. $_SERVER['PHP_SELF'] is actually a differen't variable (wibble), which isn't killed by turning off register_globals. The correct non-tilde alternative is $_SERVER['SCRIPT_URL']. Glad this is all academic now  
Gabe

[#3]

I found that I was getting server 500 errors due to the permission settings. See my post http://community.plus.net/forum/index.php/topic,84357.0.html

[#4]

Quote from: Anthony

We have a .htaccess file with the following contents:

Hi Anthony, just at first glance, RewriteEngine On line shouldn't be removed.

Quote

In Dreamweaver and using FireFTP (a Firefox extension), I try to set the permission of the root directory to 0710 but this does not apply.

Your root is already 1710 and shouldn't be changed.
Gabe

[#5]

Quote from: Anthony

My company's website is also down - we are getting a "403 Access forbidden!" message

I've fixed this for you, the permissions on the .htaccess file were too restrictive, so apache couldn't read it. If apache can't read an .htaccess file it assumes the worst and blocks access to the site.
On the new platform, .htaccess files must be readable by the group.

[#6]

@ Gabe - thanks for your help, I've added the RewriteEngine line back in
@ Ben - many thanks for this

[#7]

Quote from: Gabe

Quote from: Astronut If I am on the right track, what would be the correct path?  It's entirely possible I put the wrong one in! Right track, but you'd need to make the changes in a custom php.ini (like <a href="http://community.plus.net/forum/index.php/topic,83568.msg696223.html#msg696223">this one</a>. The path will be something like /share/storage/0X/us/username/sessions/. You can get your path from phpinfo(). Gabe

Ah, thanks Gabe!
I get the impression I need the whole file you provided pretty much as written (modified for my path) - is that correct?
Do I just place it in my root folder?  The CMS manager operates out of its own folder (/manager) - would I need a copy of the php.ini in there as well?
And just to confirm, this also lets me override the register_globals back to 'off', yes?  (I'm much happier with that setting...)
Thanks,
Jon

[#8]

Quote from: Astronut

I get the impression I need the whole file you provided pretty much as written (modified for my path) - is that correct? Do I just place it in my root folder?  The CMS manager operates out of its own folder (/manager) - would I need a copy of the php.ini in there as well? And just to confirm, this also lets me override the register_globals back to 'off', yes?  (I'm much happier with that setting...)

Yes to the first and third.
Second question: should be able to put that in your doc root but can't at the mo. It appears to be checking only the current folder for user ini, which is possibly caused by an unconfigured vhost document root. Something else for Plusnet to look at, but it looks like one ini file per script folder for now, unless I'm being dim.
Gabe

[#9]

Quote from: Gabe

Second question: should be able to put that in your doc root but can't at the mo. It appears to be checking only the current folder for user ini, which is possibly caused by an unconfigured vhost document root. Something else for Plusnet to look at, but it looks like one ini file per script folder for now, unless I'm being dim.

That figures.  I have only two folders where scripts are being executed (/ and /manager) - other folders simply hold include files which are loaded if needed.  So it looks like I only need two!
Thanks, Gabe, I'll try it tonight and see what happens...
(You know it's weird, I can produce the most convoluted and sophisticated PHP code, MySQL queries and even Regex, but anything apache-specific and my mind goes blank...)
Jon

[#10]

Quote from: Gabe

Second question: should be able to put that in your doc root but can't at the mo. It appears to be checking only the current folder for user ini, which is possibly caused by an unconfigured vhost document root. Something else for Plusnet to look at, but it looks like one ini file per script folder for now, unless I'm being dim.

I've raised this Gabe (ref: 300386).

[#11]

Unfortunately because of the way the CGI system works there isn't a specific document_root set for each user, because there isn't a virtual host for each user. I've only ever used user-generated php.ini files (as opposed to the system wide php.ini) on this and our old cgi platform, and on both of them you needed to have your php.ini in each of the folders that had scripts in. I got around this with symlinks, a quick and dirty way of doing this would be to run the following command from your home directory (via a shell script or similar)

find * -type d | while read i; do ln -s php.ini $i; done

[#12]

Thanks Bob.
Hi Ben - Absolutely. I'm not thinking, give us all a bespoke vhost root. I'm thinking, if it's faked so we're actually under the document_root, php should start searching for inis up the path. We're not under /var/www. Though my mind is getting blanker by the minute.
Gabe

[#13]

Just to confirm, I now have this done:
  Updated php.ini file with my session files relocated to sess folder in what I hope is my root and the lifetime updated.
  This file has permissions set to 600.
At present it all seems to be behaving - I'll be back if it's not!
In the meantime, thanks all, and especially Gabe for pointing me in the right direction
Jon

[#14]

I believe that I may have found the source of the non-appearing output that I detailed here.
I found a comment in the PHP manual saying

Quote

It appears that the flush() command does not work when running under suPHP. I have had it explained to me that this is due to suPHP caching all the PHP output untill the connection has been terminated, thus making this command useless.

Can I just check that we are using suPHP?
Tony

[#15]

We use suEXEC, but possibly that behaves in the same way.
David