Password protecting a web page

[WedNESday]

Hello everyone!

Long time, no see. I've been working on my web site flat out for the past 6 months or so and haven't put any effort into WedNESday in the meantime. I've also had to return to the office which has had a massive negative impact on how much programming I get to do now.

I am currently struggling to enable a page to be password protected upon attempting to access it.

Here's how things are setup:

.htaccess is located in the folder I wish to protect and looks like this:

Code: Select all

AuthType Basic
AuthName "Please login"
AuthUserFile /home/wedemu12345/.htpasswds/.htpasswd
Require valid-user

There are multiple instances of .htaccess on my site. One is located in the root directory and is totally blank (0 bytes). Another is in 'public_html' and does contain some information necessary for the site to function correctly (namely, stuff involving browser cache). The folder I want to protect is within 'public_html'.

.htpasswd contains 2 usernames and passwords. One is BCrypt and the other MD5. This is in the above location.

No matter what I do, I don't seem to be able to enter any correct username and/or password. After hitting enter, I am immediately prompted to re-enter them both again. Both files are 644 and were created and modified within cPanel's editor itself. There are no error logs.

I have tried solutions from a ton of different web sites but nothing seems to work. I use cPanel.

What am I doing wrong?

[Drag]

Can you check Apache's logs? My first thought is, some kind of access protection in the OS is going on, not allowing Apache to access files in that particular path.

Edit: Yeah, I suspect that your instance of Apache may not be able to freely access files and directories within "/home/user".

[WedNESday]

Can you check Apache's logs? My first thought is, some kind of access protection in the OS is going on, not allowing Apache to access files in that particular path.

There are absolutely 0 logs to be found anywhere. I don't even know if it's Apache that my server is running.

Could it maybe have something to do with 'AllowOverride'? I did read in a few places that it might be playing some kind of role here.

[Drag]

Well, it's prompting for a password, so I'd assume the issue is, it either can't access (path is denied by OS) or can't parse your password file (e.g., wrong line endings, wrong format, etc).

I think other issues would cause the password to just never be prompted, or for the server to serve error pages.

[WedNESday]

Interesting that you would mention that. I just checked Edge's log (F12) to see something about a 401 error. I too do believe it's a case of an access restriction.

I've just tried using the following code:

Code: Select all

<Directory "/dir1/dir2">
	AllowOverride AuthConfig
</Directory>

...inside the .htaccess files lower down the line but to no avail. I'm still at a complete loss as to what to do next.

[Drag]

Try putting your password file somewhere else? Make sure it has the correct encoding and line endings?

A 401 error in Edge means the server responded "you're not authorized to access the resource you were trying to access" i.e., the wrong password was given.

[Bavi_H]

My website uses Apache and cPanel and I recently set up a password protected folder. Here are some possible tips.

I don't even know if it's Apache that my server is running.

I think your server is using Apache.

Your cPanel page probably looks something like this image: The cPanel Interface (from the page The cPanel Interface).

To confirm what version of Apache your server is using, log into cPanel, look in the right margin General Information section, then click the link at the bottom that says "Server Information".

There are absolutely 0 logs to be found anywhere.

To access error messages or web logs, log into cPanel, look in the main tools area for the Metrics section, then click on the following icons:

"Errors" will show recent server error logs.
"Visitors" will show you a sortable table of the web log.
"Raw Access" will let you download zipped plain text web logs.

(Another way to get to these pages is by going to the search box at the top of the cPanel page and typing in Errors, Visitors or Raw Access.)

Could it maybe have something to do with 'AllowOverride'? I did read in a few places that it might be playing some kind of role here.

As you have probably learned, AllowOverride is used to enable or disable what directives will work in .htaccess files. Since the browser is prompting for a username and password, that suggests to me that the server is obeying the relevant directives in the .htaccess file in the folder you want to password protect. This makes me think AllowOverride is not causing your problem. (Or at least not AllowOverride AuthConfig.)

I've just tried using the following code:

Code: Select all

<Directory "/dir1/dir2">
	AllowOverride AuthConfig
</Directory>

...inside the .htaccess files

Be aware that Apache uses both main config files and folder-based .htaccess files. If you are on a shared server (in other words, if your hosting provider uses one IP address for multiple websites), then the main config files are only accessible and editable by your hosting provider. But you can create and edit .htaccess files in your own folders to control some of the web server settings related to your own website.

As I understand it, the AllowOverride and <Directory> directives only work in the main config files, not in .htaccess files.

In the Apache HTTP Server documentation, take a look at the .htaccess Files Tutorial and explore other topics from the links on that page as desired.

(Note that the documentation encourages using main config files instead of .htaccess files when possible. But if you are on a shared server, being able to use .htaccess files is a good thing because it lets individual website authors customize server settings for their own websites because they do not have access to the main config files.)

I just checked Edge's log (F12) to see something about a 401 error.

A 401 error in Edge means the server responded "you're not authorized to access the resource you were trying to access" i.e., the wrong password was given.

As Drag said, the server sending a 401 error to the browser just means the server thinks the username and password is missing or incorrect. In fact, the first time the server sends the 401 error is how the browser discovers it should prompt you for a username and password. However, after you enter a username and password for the browser to send, if the server still thinks the username and password is missing or incorrect it will keep sending the 401 error to the browser.

[Bavi_H]

My Test of Unreadable Password File

In my cPanel, I went to the Files section and used the "Directory Privacy" item to set up a password protected folder. After going though that process, cPanel automatically created the .htaccess file in the web folder I selected, and created a corresponding password file elsewhere in my user folder. The .htaccess file that cPanel created in the web folder contained the same four directives WedNESday mentioned in the first post.

In my cPanel "Directory Privacy" pages, there was no option to choose the password encryption format. When I look in the password file cPanel created, it looks like cPanel used Apache's MD5 format to encrypt the password, because the encrypted password begins with $apr1$. (See the Apache documentation about Password Formats.)

Next, I intentionally made the password file unreadable by turning off all the permission flags to 000. When I used my web browser to visit the protected folder, the browser prompted for a username and password, then when I entered them, an error 500 "Internal Server Error" page was returned. The cPanel "Errors" page showed this corresponding error:

[time] [authn_file:error] [pid x:tid y] (z)Permission denied: [remote ip:port] AH01620: Could not open password file: /path/file

[Bavi_H]

Disable Server Compression? Put Username And Password In URL?

Here is a recent issue I encountered with a password protected folder.

I password protected a folder with a large file in it in order to share the file with someone else. The other person was able to visit the link to the file, enter the username and password, and the download would start, but the download would get interrupted. After each interruption, the download would start over from the beginning. Also, their browser kept re-prompting for the username and password.

To avoid having to re-enter the username and password each time, I suggested they try the URL format that includes the username and password in the URL itself:

https://username:password@example.com/folder/file.ext

(Note: I think some modern browsers block this URL format, try it and see if works in your browser.)

That helped them avoid having to re-enter the username and password, but they were still having problems with the download getting interrupted and starting over from the beginning.

I used my browser's Developer Tools Network page to look at the response headers the server was sending. I noticed the server was not sending a Content-Length header for the password-protected large file. If I remember correctly, I also noticed other response headers that indicated the server was compressing the response. I realized the server couldn't know what the size of the response was going to be in advance, so it couldn't send a Content-Length value. And because the server was compressing the file on the fly, the server was unable to resume an interrupted download.

Since the large file was already a zipped archive file, it didn't need to be compressed again by the server. After some research how to disable server compression, I ended up adding the following lines at the bottom of the .htaccess file in the password-protected folder:

Code: Select all

SetEnv no-gzip
SetEnv no-brotli

Then the server was able to send the Content-Length value and able to resume an interrupted download.

Thinking about again now, I wonder if their browser's initial attempts to resume the download getting denied by the server were interpreted as a generic failure and causing the browser to re-prompt for the username and password. (Since the other person had started using the URL format that includes the username and password, we never specifically tested if disabling the server compression so the download was resumable would have also helped the browser remember and reuse the username and password entered at the log in prompt.)

[WedNESday]

Guys, I just wanna firstly say a big thanks to both of you for your support on this matter.

Secondly, I just managed to solve the problem. It turns out, I had entered the MD5 hash incorrectly into .htpasswd.

D'oh!

[Drag]

Nice! At least the solution was something simple and not a "let's comb through the exact configuration of your shared web server" situation.