Plesk Question posted in
The official documentation for Plesk Obsidian can be found here.

Why might Apache forbid me from visiting this page? – Plesk

Until recently, an internal Bugzilla install was working fine. Now, all requests to pages inside the http://example.com/bugzilla directory return 403/Forbidden. Pages outside that directory, for instance at http://example.com/test.html or http://example.com/test/index.html work as expected. This is the .htaccess file for the bugzilla directory, which is unchanged from the original:

# Don't allow people to retrieve non-cgi executable files or our private data

<FilesMatch (.pm|.pl|.tmpl|localconfig.*)$>
  deny from all
</FilesMatch>

<IfModule mod_expires.c>
    <IfModule mod_headers.c>
        <IfModule mod_env.c>
          <FilesMatch (.js|.css)$>
            ExpiresActive On
            # According to RFC 2616, "1 year in the future" means "never expire".
            # We change the name of the file's URL whenever its modification date
            # changes, so browsers can cache any individual JS or CSS URL forever.
            # However, since all JS and CSS URLs involve a ? in them (for the changing
            # name) we have to explicitly set an Expires header or browsers won't
            # *ever* cache them.
            ExpiresDefault "now plus 1 years"
            Header append Cache-Control "public"
          </FilesMatch>

          # This lets Bugzilla know that we are properly sending Cache-Control
          # and Expires headers for CSS and JS files.
          SetEnv BZ_CACHE_CONTROL 1
        </IfModule>
    </IfModule>
</IfModule>

AddHandler cgi-script .cgi .pl
DirectoryIndex index.cgi

This is the .htaccess file for the directory above the bugzilla directory. This is the public_html web root:

DirectoryIndex index.html

This is the Apache configuration file for the site:

<VirtualHost *:80>
    ServerAdmin webmaster@localhost

    DocumentRoot /var/www/default/public_html
    <Directory />
        Options FollowSymLinks
        AllowOverride None
    </Directory>
    <Directory /var/www/default/public_html>
        DirectoryIndex index.cgi
        AllowOverride Limit FileInfo Indexes
        AddHandler cgi-script .cgi
        Options Indexes FollowSymLinks MultiViews +ExecCGI -MultiViews +SymLinksIfOwnerMatch
        Order allow,deny
        allow from all
    </Directory>

    ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
    <Directory "/usr/lib/cgi-bin">
        AllowOverride None
        Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
        Order allow,deny
        Allow from all
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/error.log

    # Possible values include: debug, info, notice, warn, error, crit,
    # alert, emerg.
    LogLevel warn

    CustomLog ${APACHE_LOG_DIR}/access.log combined

    Alias /doc/ "/usr/share/doc/"
    <Directory "/usr/share/doc/">
        Options Indexes MultiViews FollowSymLinks
        AllowOverride None
        Order deny,allow
        Deny from all
        Allow from 127.0.0.0/255.0.0.0 ::1/128
    </Directory>

</VirtualHost>

Note that even non-Bugzilla static HTML files in that directory are affected. For instance, I create /bugzilla/test.html in VIM, then I try to access it in the browser and see that it is also returning 403/Forbidden. All files, both in and outside that directory, have the same user ubuntu and the same permissions 644. The bugzilla directory itself has permissions 755, as does its parent public_html.

No ‘control panels’ such as Plesk are installed on the server, all configuration is done in Apache config files. Why might Apache have decided that I may not be authorized to view the bugzilla directory? This is on a public webserver hosted in Amazon Web Services, on Ubuntu Server 12.04 LTS.

Tags:

2

Answers


  1. 0

    Check the error_log file, it usually has very detailed information about why it returns a 403 Forbidden.

    Login or Signup to reply.
  2. 0

    (It looks like a debian server? If you post questions like this, always mention the OS.)

    I suspect it to be a rights issue – wrong owner. For debian/ubuntu, the given folder and its files should be owned by user “www-data”. For Centos/Redhat I believe it should be “nobody”. Check it, change it if necessary. 

    sudo chown -R www-data:www-data test

    NB: If you’re unsure about changing rights, make a copy first. Change the owner of the copy, as copying in itself probably changes the owner. Or use rsync to make a copy of the folder, as rsync preserves owner and rights.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search