403 Forbidden Apache error

Uit De Vliegende Brigade
Naar navigatie springen Naar zoeken springen

An Apache 403 error, also known as "403 Forbidden," is an HTTP status code that indicates the server understood the request, but it refuses to authorize it. In simpler terms, it means the server is refusing to fulfill the request due to insufficient permissions. There are several reasons why you might encounter a 403 error:

  • Insufficient permissions: The user trying to access the resource doesn't have the necessary permissions
  • Incorrect file or directory permissions: The file or directory you're trying to access doesn't have the appropriate permissions set. This could be due to incorrect permissions set by the server administrator or a misconfiguration
  • IP blocking or access restrictions: The server may be configured to block access from certain IP addresses or ranges, or it may have other access restrictions in place
  • Authentication issues: If the resource requires authentication, but the user hasn't provided valid credentials, or the credentials provided are incorrect, the server will return a 403 error
  • Resource availability: Sometimes, the server may return a 403 error if the requested resource is unavailable for some reason, such as being temporarily offline or removed.

When troubleshooting a 403 error, it's essential to check the server logs for more detailed information about why the request was forbidden. This can help pinpoint the exact cause of the error and guide the resolution process.

One way to access the Apache error log:

tail /var/log/apache2/error.log

Due to index.php?

It's possible that the issue lies within the PHP file itself, especially if the PHP code includes logic or configurations that restrict access based on specific conditions such as the URL or client IP address. Here are some scenarios where the PHP file itself could be causing the access denial:

  • URL-based restrictions: The PHP code may contain logic to restrict access based on the URL from which the request originated. If the PHP file contains code to check the URL and deny access to certain URLs, it could lead to the server denying access when the site is cloned to another URL
  • IP-based restrictions: Similarly, the PHP code may include IP-based access restrictions that deny access to certain clients or IP ranges. If the cloned site is accessed from an IP address that is restricted by the PHP code, it could result in the server denying access
  • Authentication: The PHP code may require authentication, and if the credentials provided are incorrect or missing, it could lead to access denial.

Case: After migration to laptop (2024.04)

Context: Cloning a website from a webserver to my laptop for testing & troubleshooting.

Possible causes:

  • Specific server-sided stuff, like caching. Maybe through /wp-admin.php
  • Stuff in wp-config.php that indicates that the site shouldn't be available under another URL

Additional information

  • Placing a index.html file in the root of the site, worked: The html file got just executed as expected. Placing back the index.php recreated the problem
  • Liberating file rights, didn't make a change - Up to 777
  • Renaming and later removing .htaccess file - No difference
  • Removing anything from wp-config.php related to maybe other things like caching - No difference.

Last 4 log lines (only the last 2 are actually relevant, in hindsight):

[mpm_prefork:notice] [pid 926] AH00163: Apache/2.4.41 (Ubuntu) configured -- resuming normal operations
[core:notice] [pid 926] AH00094: Command line: '/usr/sbin/apache2'
[access_compat:error] [pid 949]   [client 127.0.0.1:39434] AH01797: client denied by server configuration: /var/www/de.de/index.php
[access_compat:error] [pid 19893] [client 127.0.0.1:39438] AH01797: client denied by server configuration: /var/www/de.de/index.php
Etc.

The [access_compat:error] part of the log entry suggests that the issue might be related to the Apache module mod_access_compat, which provides compatibility with the older access control syntax used in Apache 2.2.

Note that it looks like the index.php, hasn't been executed yet, but there is an issue with the access module. There is nothing like that in the actual index.php file → Check for something around Apache, e.g., here sudo vim /etc/apache2/sites-available/de.de.conf → Got it:

Cause

There was an old version of the script add_domain. It contained the erroneous lines:

<FilesMatch "\.php$">
   Deny from all
</FilesMatch>

and that caused the problem: No PHP file was allowed to be executed.

Review

How to do this faster next time:

  • Fix that wrong script
  • ChatGPT really helped - quite a surprise
  • Use log files
  • Look for the details: The fact that index.php didn't seem to get executed, was quite a hint.