Web Dev Intensive

Overview

HTTP is the protocol which web browsers and web servers use to communicate via client requests and server responses, respectively.  We’ve seen that the browser uses HTTP GET and POST methods to request data from the server.

HTTP also provides a very basic level of authentication which you can use to password-protect your sites or certain folders within your sites.  And Apache servers, such as our class server, make it is possible to use this authentication system by simply writing a bit of special code in a file called .htaccess.

We have previously used .htaccess files for rewriting URLs to create Fancy URLs.  The .htaccess file is a directory-specific configuration file – it can hold a variety of server settings that apply only to the folder in which you place it.  This post is about one such setting.

Password-protecting a folder

To password protect a specific folder, we will create two files: one named .htaccess and another named .htpasswd.

.htaccess holds the server instructions indicating that the folder should be password protected.  This file gets placed in the folder which you want to password protect.

.htpasswd holds the username/password combinations of users who are allowed to view the folder.  Passwords are encrypted.  This gets placed somewhere on the server where it is not accessible from the web – you don’t want people loading this file up directly in their web browsers.

The .htaccess file

The .htaccess file contains the following code.

AuthUserFile <the server path to the folder where your .htpasswd file will live>/.htpasswd
AuthGroupFile /dev/null
AuthName EnterPassword
AuthType Basic

Replace <the server path to the folder where your .htpasswd file will live> with the path to your own .htpasswd file.  Ideally this will be somewhere outside of the web root of the server.  On the class server, the web root is the folder /home/scps/onepotcooking.com/

As an aside, saying this is the “web root” means that when a user goes to http://onepotcooking.com in their browser, they will by default view the files in the folder /home/scps/onepotcooking.com.  The “server root” is /, the very topmost folder on the server.

So, if your name is George Washington, perhaps put your .htpasswd file at

/home/scps/passwords/georgewashington/.htpasswd

so it is outside of the web root, yet still somewhere you might be able to find it again if you ever went looking.

The .htpasswd file

The .htpasswd file will contain one of the following lines for each user that has access to the protected folder:

<username>:<encrypted password>

Replace <username> with the username of the user you want to give access.  And replace <encrypted password> with an encrypted password for that user.

How do you get an encrypted password?  You use one of the many websites that encrypt your .htpasswd passwords for you for free, such as this one.

So, for example, if your username is “scps” and your encrypted password is “pnzpsMNdWW6aw”, you will put the following line in your .htpasswd file:

scps:pnzpsMNdWW6aw

And you will save this .htpasswd file into the folder that you indicated in the first line of your .htaccess file.

An example

See an example here.  The username is our standard username, and the password is our standard password minus the last character.  You’ll notice that I have been naughty and put the .htpasswd file in the same folder as the .htaccess file.  On a real site you shouldn’t put it anywhere where a web browser can find it.

How it works

Here’s an overview of the steps that are happening behind the scenes to make this system work:

1. Your client (most likely your web browser) makes a standard HTTP GET request for a password protected area of the server
2. The server looks for any .htaccess file in the requested folder
3. The server reads the .htaccess file and sees that the requested file or folder should be password protected
4. The server responds to the client with an HTTP HTTP response code indicating that the requested file is password protected.
5. The browser is built to know what to do with this response code: it pops up a dialog that the user must fill in with a username and password
6. The user fills in the username and password and clicks submit
7. The client sends another HTTP GET request to the server, but this time includes the login credentials as extra HTTP headers along with the request.
8. The server again looks at the .htaccess file and sees that the requested file or folder is password protected, but this time notices that the client included the necessary login credentials along with the request
9. The server responds to the client with the requested page
10. The client stores the login credentials the user entered somewhere on the client machine (similar to a cookie) so that next time the page is requested, it doesn’t have to ask the user to enter them again.  The client just sends them to the server in the HTTP headers automatically.

Loading a web page involves multiple requests for various files from the server

When a user loads a web page in a web browser, a sequence of HTTP requests are made to the server for the various files necessary to display the web page properly in the browser.

For example, let’s say a user loads this site, http://wd.onepotcooking.com/.  Here is a set of steps that may be triggered as a result of a simple action such as this:

• Typing that URL in the address bar and clicking “go” causes the browser to make an HTTP request to the wd.onepotcooking.com server for the default web page at that address.
• The server finds the file on its hard drive that contains the default HTML code for the requested page of the site, and sends that code to the browser as part of its HTTP response to the browser’s initial request.
• The web browser then may automatically send another request for the default favicon file that goes along with the requested website.  The favicon file is the little image that sometimes shows up next to the address in the web browser.
• The server will try to find the favicon file that goes along with the requested web page on its hard drive, and if such a file exists, it will send the contents of that file back to the browser as part of its HTTP response.
• The web browser will eventually start analyzing the HTML code it received back from the server in response to its first request.  The HTML code may indicate to the browser that there are other files necessary in order to display the requested web page properly in the browser.  These might include CSS files that contain style and design information about the page, Javascript files that define interactive behaviors that should happen on the page, image files that are used for graphics or photos on the page, and other file types such as Flash animations, Java applets, and a variety of other more obscure types of content that may show up on some web pages.
• The web browser will go through this list of files and request them one-by-one from the web server using the same HTTP request/response mechanism until all files that are necessary to display the web page properly have been received from the web server.
• Finally, the web page shows up nicely in the web browser and the user is happy.