My problem:
For some reason my custom 401 error page is not displaying on login and is just displaying the generic 401 error page:
Unauthorized
This server could not verify that you are authorized to access the document requested.
Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't
understand how to supply the credentials required.
Additionally, a 401 Unauthorized error was encountered while trying to use an
ErrorDocument to handle the request.
Now in saying this my custom 404 error page and others are displaying just fine, just not for the 401. The "error.php" (custom error page) file is in my public_html directory.
My current .htaccess file in public_html directory:
ErrorDocument 400 /error.php
ErrorDocument 401 /error.php
ErrorDocument 402 /error.php
ErrorDocument 403 /error.php
ErrorDocument 404 /error.php
ErrorDocument 500 /error.php
ErrorDocument 501 /error.php
ErrorDocument 502 /error.php
ErrorDocument 503 /error.php
ErrorDocument 504 /error.php
ErrorDocument 505 /error.php
ErrorDocument 506 /error.php
ErrorDocument 507 /error.php
ErrorDocument 510 /error.php
RewriteEngine On
DirectoryIndex .index.php .style.css .sorttable
RewriteRule .*\.(jpg|jpeg|gif|png|bmp|zip|rar)$ - [F,NC]
# php -- BEGIN cPanel-generated handler, do not edit
# Set the “ea-php73” package as the default “PHP” programming language.
<IfModule mime_module>
AddHandler application/x-httpd-ea-php73 .php .php7 .phtml
</IfModule>
# php -- END cPanel-generated handler, do not edit
#----------------------------------------------------------------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 "Protected 'public_html'"
AuthUserFile "/home/dark/.htpasswds/public_html/passwd"
Require valid-user
#----------------------------------------------------------------cp:ppd
# End section managed by cPanel: Password Protected Directories -cp:ppd
#----------------------------------------------------------------cp:ppd
Now my directories are password protected as you can see in the .htaccess. I tried the following fixes but still no luck on displaying the custom 401 error page:
Created the error page in a different directory.
Specified the complete url of the error page in the .htaccess file.
Turned off the directory password function.
Changed the error file extension to .shtml.
Tried many other codes and questions on the stackoverflow website.
Now to recap, all other custom error pages are displaying fine, just not the 401 on login and i'm stumped.
My cPanel Sever Information:
Hosting Package Gold
Server Name server
cPanel Version 88.0 (build 14)
Apache Version 2.4.46
PHP Version 7.3.21
MySQL Version 10.3.24-MariaDB-cll-lve
Architecture x86_64
Operating System linux
Shared IP Address 45.95
Local IP Address 192.168
Path to Sendmail /usr/sbin/sendmail
Path to Perl /usr/bin/perl
Perl Version 5.16.3
Kernel Version 3.10.0-962.3.2.lve1.5.32.el7.x86_64
Thanks!
For the 401 ErrorDocument to be served, it needs to be accessible. If everything is blocked behind HTTP authentication then it's not going to be accessible when authentication fails and you get the additional part in the default server 401 response:
Additionally, a 401 Unauthorized error was encountered while trying to use an
ErrorDocument to handle the request.
You need to "punch a hole" in your authentication and allow public access to this document.
For example:
<Files "error.php">
Require all granted
</Files>
Created the error page in a different directory.
That should have worked, providing the "different directory" was not also protected by HTTP authentication. For instance, a subdirectory would not help.
Specified the complete url of the error page in the .htaccess file.
That would trigger an external 302 redirect and lose the 401 response. This is not permitted. As noted in the Apache docs:
if you use an ErrorDocument 401 directive, then it must refer to a local document.
Turned off the directory password function.
If you turned "off the directory password function" then there's nothing to trigger the 401 so your error document would be accessible, but then how are your triggering/testing your 401 error document? This seems a bit chicken/egg.
Changed the error file extension to .shtml.
Changing the type of file would make no difference here.
RewriteRule .*\.(jpg|jpeg|gif|png|bmp|zip|rar)$ - [F,NC]
To clarify, you're not serving any images on any pages? Any request that contains one of these file extensions will trigger a 403 Forbidden.
UPDATE: If your error documents use additional resources then it would be easier for these all to be self contained in their own subdirectory (eg. /errordocs) - you can then just permit public access to this subdirectory without having to identify every file.
You then create an additional .htaccess file in the /errordocs subdirectory with just a one liner:
Require all granted
Related
The first few lines of my .htaccess file are as follows.
ErrorDocument 400 https://www.rydercragie.com
ErrorDocument 401 https://www.rydercragie.com
ErrorDocument 403 https://www.rydercragie.com
ErrorDocument 404 https://www.rydercragie.com
ErrorDocument 500 https://www.rydercragie.com
They all work apart from https://RyderCragie.com/.htaccess. Any ideas why an error is still shown on that page and how to fix it? Thanks.
Requests for .htaccess are quite likely blocked by directives in the server config - before the ErrorDocument in .htaccess is processed.
In order to catch this, you would need to define the ErrorDocument earlier in the main server config, not .htaccess. The same applies to other requests that are blocked early by Apache, such as requests that contain encoded slashes in the URL-path, and most 500 errors.
Although any request for .htaccess in the wild is unquestionably malicious, so a minimal (default) server response is probably the best response.
However, implementing all your ErrorDocument directives as external redirects to the document root is generally a bad idea (you lose details of the request that triggered the response, bad experience for users, etc.)
Give your user a meaningful error response, without the redirect. Error documents should be served via an internal subrequest. For example:
ErrorDocument 403 /error-documents/e403.html
Reference:
https://httpd.apache.org/docs/2.4/mod/core.html#errordocument
I am trying to redirect the user to a page when 404 error occurred, so I am writing
ErrorDocument 404 /error.html
In .htaccess file and having an error.html file in my root directory but it's giving me
The requested URL was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
Try resetting the error document to the system default prior to setting your custom document. For example:
ErrorDocument 404 default
ErrorDocument 404 /error.html
On some shared servers, the error document is (incorrectly) preconfigured in the main server config.
I have customized error pages setup on my site for the 302, 401, 403, 404 and 500 HTTP error codes. The five custom error page files are stored in the home directory.
I would also like to protect a specific directory with a password and have tried doing so with cPanel's "Password Protect Directories" feature.
I should also mention that in the home directory, there is an .htaccess file, with the following:
<limit GET POST PUT>
order deny,allow
allow from all
</limit>
Options -Indexes
ErrorDocument 302 /302.php
ErrorDocument 401 /401.php
ErrorDocument 403 /403.php
ErrorDocument 404 /404.php
ErrorDocument 500 /500.php
With that out of the way, I can now explain what's currently happening with this setup. Essentially, rather than the web browser prompting for the username and password, the password-protected page simply goes straight to the 401.php error page.
I've tried moving the error pages to their own directory, /error/, I've tried using cPanel's own error page setup tool (which uses .shtml files), and I've also tried a combination of cPanel's error pages and my own.
From my testing, it seems that cPanel's .shtml error pages work, but they are ugly and don't match the theme of the website. The error pages I made, use PHP to require files for the theme, as well as to echo back the user's requested URL.
I also seemingly had the combination of both sets of error pages working, even after I reuploaded the home directory's .htaccess file, but upon removing the set that cPanel made, everything broke again. I also don't know if it's good practice to use two sets of error pages, as follows:
<HOME_DIR>
--- <DIR>
--- .htaccess (contains code for password protection)
--- index.php
--- .htaccess (links to PHP error pages)
--- 302.php
--- 302.shtml
--- 401.php
--- 401.shtml
--- 403.php
--- 403.shtml
--- 404.php
--- 404.shtml
--- 500.php
--- 500.shtml
--- index.php
This is something that I've never experienced before. From what I can ascertain, the problem is coming from the .htaccess file under the home directory, but I'm not 100% on that.
Lastly, here is the .htaccess file that cPanel created when I set up the password protection (note: "<USER>" and "<DIR>" have been used for privacy) :
AuthType Basic
AuthName "Authentication Required"
AuthUserFile "/home/<USER>/.htpasswds/public_html/<DIR>/passwd"
require valid-user
It's an Apache server, by the way. Many thanks for any advice.
Temporary rename .htaccess file in which you have added ErrorDocument rule and then clear your browser cache and cookies. Now try to access your password protected URL. If it works, copy your ErrorDocument code and add it after password protection rules.
An Indirect Solution
It appears that I've had to convert the error page files from .php to .shtml format. Along with that, all PHP require statements have been removed in favor of plain HTML (as I couldn't get them working, not even with SSI's #include statement), and lastly I've had to replace the PHP echo for the requested URL in favor of an SSI #echo.
This was more work than necessary for such a mundane thing. I have no idea why PHP conflicted with password-protected directories. This hasn't happened before as I've used PHP error pages in the past. It must be some kind of conflict between PHP and the password protection.
Well, for what it's worth, there's a 'solution'.
I have a structure like this on a shared host:
~/above_public_html/public_html/directory_i_want_forbidden
I have an ~/above_public_html/.htaccess with the following:
ErrorDocument 403 /403.html
ErrorDocument 404 /404.html
When I navigate to a file or folder that doesn't exist, I get the 404.html popping up, no problems.
When I navigate to a subfolder or file that exists but has chmod 700 permissions (including the directory_i_want_forbidden), I get:
Forbidden
You don't have permission to access /directory_i_want_forbidden on this server.
Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.
Apache Server at www.mydomain.com Port 80
What do I need to do in order to make the ErrorDocument 403 /403.html work correctly?
Something was screwy with the .htaccess or httpd.conf upstream. I had no control over it since I was on shared hosting. I have since started my own Amazon EC2 server-instance and everything is working as it should.
I have a site hosted on an Apache server. I have created some custom error pages and the following text at the top of my .htaccess file:
ErrorDocument 404 404.html
ErrorDocument 500 500.html
ErrorDocument 401 401.html
I have also tried,
ErrorDocument 404 /404.html
ErrorDocument 500 /500.html
ErrorDocument 401 /401.html
Both the htaccess file and the custom pages are in the root directory of the server.
The problem is that when I enter a garbage url (where I would expect to see my custom 404 page) I'm simply being redirected to my index page.
Try if your server is properly set up to parse and process .htaccess files in the first place (i.e., check if AllowOverride + AccessFileName directives are correct). For example, write some stuff in that you know will work and look if it actually gets executed (like a ridiculous rewrite rule). Also, look up your httpd log files for errors.
If it does get executed properly, the problem might be that your server is setup not to allow all kinds of overrides with .htaccess files. Your syntax however, is basically correct.