Support » Localhost Installs » WP ignores .htaccess ErrorDocument 401

  • I created a protected directory using cPanel. Location is /files/members
    cPanel created /files/members/.htaccess as follows:

    #—————————————————————-cp:ppd
    # Section managed by cPanel: Password Protected Directories -cp:ppd
    # – Do not edit this section of the htaccess file! -cp:ppd
    #—————————————————————-cp:ppd
    AuthType Basic
    AuthName “Members Only”
    AuthUserFile “/home/cnr/.htpasswds/public_html/files/members/passwd”
    Require valid-user
    #—————————————————————-cp:ppd
    # End section managed by cPanel: Password Protected Directories -cp:ppd
    #—————————————————————-cp:ppd

    Boiler plate as can be. For those with experience here, you know that accessing this directory by direct URL (mywebsite.com/files/members, where WordPress 5.6.2 is installed in the root) results in the confusing 404 -page not found error (even though the actual error is 401 – authorization required), instead of the desired directory access credentials popup.

    The standard fix is to add “ErrorDocument 401 /401.html” and optionally “ErrorDocument 403 /401.html” in the root WP .htaccess file BEFORE the “# BEGIN WordPress” section. Which I have done, as well as created the 401.html file, placing it in the root.

    Guess, what? WP IGNORES this and continues to return 404. No, I don’t have any caching enabled. Changes to .htaccess are picked up immediately on page refresh (I tested with other options/commands/rules to confirm).

    Has .htaccess syntax changed in the last 2 years making the above ErrorDocument method invalid or has WP added something I need to address in Settings that’s being overlooked?

    According to all the google search hits, adding ErrorDocument to the root .htaccess has fixed EVERYONE else’s 404’s on protected directories, but NOT ME!! Any possible info/help is kindly appreciated.

    I have also added “Options +Indexes” beneath “# END WordPress” to allow a file index to be displayed for any directory that doesn’t have a protective index.php intercept file in them. I don’t see how that could cause WP to “ignore” ErrorDocument.

    Thanks.

    • This topic was modified 1 month, 2 weeks ago by chrusion.
Viewing 5 replies - 1 through 5 (of 5 total)
  • TL;DR: This has nothing to do with WordPress, but cPanel’s quirks plus your wrong error document file and path. Simple fix: make sure you have a 401.shtml file in your public_html folder, even a blank one will do. Note the file extension: .shtml, not .html. You don’t even need to add the custom errorDocument directive, but if you do add one, it better be correct: use the correct file extension and full server file path.

    And now my original long explanation (feel free to skip 😀 )

    Often, our untested assumptions can lead us in the wrong direction.

    WordPress is not a web server and can’t process any .htaccess rules. Your Apache webserver does. WordPress only adds its own rules in the .htaccess files for the Apache webserver to process.

    If your custom .htacess rules are being ignored, it’s your Apache web server that is ignoring them, not WordPress. Because, again, WordPress cannot do anything with these rules… because these are Apache webserver rules.

    And your webserver would be ignoring the directive for good reason: it’s wrong.

    For those with experience here, you know that accessing this directory by direct URL (mywebsite.com/files/members, where WordPress 5.6.2 is installed in the root) results in the confusing 404 -page not found error (even though the actual error is 401 – authorization required), instead of the desired directory access credentials popup.

    I just rolled out a new WHM/cPanel server just to test out what’s going on here.

    From my quick test, it appears what’s going on here is logical, as explained below:

    Upon inspecting the server logs, it seems Apache initially sends the expected 401 response code. But somehow (and I’ve not really understood why this is happening), the server is not able to display the server-wide 401 errorDocument page, leading to a 404 response code being returned… which WordPress takes over and displays it’s own 404 page.

    So, WordPress is dsplaying your theme’s 404 error page, because the server (Apache) is returning a 404 HTTP response. Again, WordPress itself cannot process the .htaccess directives in any way.

    In my case, the solution was to simply create a blank 401.shtml file in the cPanel account’s public_html folder. Note the file extension is .shtml.html doesn’t work. You can create this file manually, or, preferably, use cPanel’s “ERROR PAGES” feature to generate the file automatically.

    This seems to be a cPanel/WHM-specific issue… as I tested protected directories on a properly configured custom VPS (with no control panel)… and the server returned the 401 response code, the URL showed the HTTP auth popup in the browser, and on cancelling, the configured 401 error document page was displayed.

    Good luck!

    Thread Starter chrusion

    (@chrusion)

    Thanks for the explanation. I understood WP doesn’t process .htaccess. I was imprecise in saying it was ignoring the error directives. I did the changes you said (changed 401.html in /public_html to 401.shtml, and removed ErrorDocument 401 and 403 from root .htaccess). Apache is still sending a 404 for the direct url to the protected folder.

    Here’s the full .htaccess:

    Options +Indexes
    RewriteOptions inherit

    # BEGIN WordPress
    # The directives (lines) between “BEGIN WordPress” and “END WordPress” are
    # dynamically generated, and should only be modified via WordPress filters.
    # Any changes to the directives between these markers will be overwritten.
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteRule .* – [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
    RewriteBase /
    RewriteRule ^index\.php$ – [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>
    # END WordPress

    # BEGIN cPanel-generated php ini directives, do not edit
    # Manual editing of this file may result in unexpected behavior.
    # To make changes to this file, use the cPanel MultiPHP INI Editor (Home >> Software >> MultiPHP INI Editor)
    # For more information, read our documentation (https://go.cpanel.net/EA4ModifyINI)
    <IfModule php7_module>
    php_value date.timezone “US/Eastern”
    php_flag display_errors Off
    php_value max_execution_time 30
    php_value max_input_time 60
    php_value max_input_vars 1000
    php_value memory_limit 64M
    php_value post_max_size 505M
    php_value session.gc_maxlifetime 1440
    php_value session.save_path “/var/cpanel/php/sessions/ea-php74”
    php_value upload_max_filesize 500M
    php_flag zlib.output_compression Off
    </IfModule>
    <IfModule lsapi_module>
    php_value date.timezone “US/Eastern”
    php_flag display_errors Off
    php_value max_execution_time 30
    php_value max_input_time 60
    php_value max_input_vars 1000
    php_value memory_limit 64M
    php_value post_max_size 505M
    php_value session.gc_maxlifetime 1440
    php_value session.save_path “/var/cpanel/php/sessions/ea-php74”
    php_value upload_max_filesize 500M
    php_flag zlib.output_compression Off
    </IfModule>
    # END cPanel-generated php ini directives, do not edit

    # php — BEGIN cPanel-generated handler, do not edit
    # Set the “ea-php74” package as the default “PHP” programming language.
    <IfModule mime_module>
    AddHandler application/x-httpd-ea-php74 .php .php7 .phtml
    </IfModule>
    # php — END cPanel-generated handler, do not edit

    Anything in WHM I should be checking? This is a VPS account with Liquidweb.

    Dion

    (@diondesigns)

    Since your issue is clearly cPanel-related, I strongly suggest that you head over to https://forums.cpanel.net and post your question there.

    For what it’s worth, since you have a VPS using cPanel, the best place for your ErrorDocument directives is within a <Directory> block in a pre_virtualhost_global.conf file. If you don’t know what that file is, take a look at the main httpd.conf file…it’s documented there. You’ll need to restart Apache to activate any changes to the system configuration. (If you have a managed VPS at LiquidWeb, ask them to do it for you.)

    Thread Starter chrusion

    (@chrusion)

    Liquidweb support didn’t find any Apache or cPanel config issues. They removed my cPanel protected dir (deleted .htaccess in the protected dir) and created a new one via cPanel. Same freakin exact commands/format as the one cPanel created for me. EXCEPT, they added “ErrorDocument 401 /401.html” as the first line (NOT SHTML as you indicated was the required file extension). They also created a new user and password. They did not touch the root .htaccess, which still has the old “ErrorDocument 401 /401.shtml” directive I added per above reply.

    For whatever reason, THIS “solution” worked (no more 404 for WP to handle).

    Strange thing is, I did this EXACT same thing (adding “ErrorDocument 401 /401.html” to the protected dir’s .htaccess file, BEFORE posting here. Why it worked for them and not me… <total shrug fest>.

    Dion

    (@diondesigns)

    I can almost guarantee that LiquidWeb made a change in your global Apache configuration without telling you. That’s why things “magically” worked when they made the exact same change you did. (This is standard operating procedure at many/most managed VPS hosting cvmpanies.)

Viewing 5 replies - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.