Session Management and Authentication with PHPLIB Page 2

Now let’s take a look at what the features do.

Authentication PHP uses an authentication mechanism that is more flexible than basic authentication, as well as being reasonably secure. Here’s how it works. At the top of your protected page, you have a page_open call which contains the statement “auth” => “auth_class” where auth_class is the name of your authentication class. The page_open function evaluates this, and initializes the authentication component. Authentication first checks to see if the user is already authenticated. Let’s assume that our user just arrived, and is not yet authenticated. PHPLIB will present the user with a login form (no popup windows!!!), which you may design yourself or use the included one. The user enters their username and password, and clicks submit. Simple, eh? What goes on behind the scenes is a bit more complicated… If the user does not have a JavaScript capable browser, then authentication works much like you would suspect. The username and password are sent to the server, and compared against the values stored in the database. If the user does have a JavaScript capable browser, it’s a bit different. PHPLIB will put a string in the form called a “challenge”. When the user submits the form, their username, password, and the challenge are encrypted using an md5 encryption algorithm. The only thing that is passed back to the server is the username, and this encrypted hash (password is NOT transmitted). The server then takes the same challenge string, the username submitted, and the password associated with that username in the database. These values are also encrypted with md5. The two encrypted strings are then compared. If they match, the user submitted the correct password, and is allowed to proceed. So, the user is authenticated with the password never having been transmitted, so it cannot be sniffed. Very slick. Session Management Authentication ties in very closely with session management. Once the user is authenticated, their session begins. If the user has a browser that supports cookies, a session id is created by making an md5 hash of a php uniquid (a random id based on system time) and an arbitrary string. The cookie is a session cookie, meaning that it is never written to the user’s hard disk, and it is removed once the session ends. If they do not support cookies, the same session id is stored as a get parameter in the URL.The md5 hash is done so that the session id is random, and it is not possible to guess one session id based on knowledge of another one. The session id is used to store information about the user in the system. This information can include if the user is authenticated, when their authentication exprires (Yep, you can do expiration!), what permissions they have (coming later), and any other information you want.

Aside: PHP and Object Oriented Programming PHPLIB uses PHP’s OOP feature extensively. This may be the first time you’ve seen it in use, so it’s going to help a lot if you have an idea of what it all means. The first step is to not really think of it as object oriented. Rather, it’s a way to group together data and functions for convenient access. It does not follow many OO conventions, and it is not truly object oriented. With that said, let’s look at the database class to see what it means. <?php $db = new MyDBClass; ?> This line creates a new database object. Think of it as initializing all the functions in MyDBClass so that you can use them. $db is then a link to this database object. In a real OO language, creating this object would simply allocate memory for the data and functions. With PHP, what it does is essentially set up the object (in this case, basically set up the database connection, and select the database). To do anything useful with this object, you evoke methods on it. Methods are simply functions that manipulate an object’s data. For example, <?php $db->query($query); ?> means to evoke the function query on the database object $db. The query method takes the string you pass it, and uses the data in the database object to execute that query. The -> symbol may confuse you a bit. In C, -> means to access the data of a pointer to a structure. In PHP, it means that the method on the right is called on the object on the left. Here, query is just one of the functions in the database class. All the other functions in that class can be accessed in the same way. Now, when you set up your local.inc file, you do so by extending classes. Extending is an OO word for adding functionality to things. When you extend a class, all the functions and data in the class you are extending (called the super class) is available to the extending class (called the sub class). Your subclass can add functionality to the superclass, and it can also overwrite data and methods in the superclass. Let’s take the database example. Here is a subclass of a database class: class MyDBClass extends DB_Sql {     $Host     = "localhost";     $Database = "some_database";     $User     = "some_db_user";     $Password = "db_user_password"; } Here we are creating a class called MyDBClass. This class can do everything that the database class can do. However, it has replaced some of the data of the database class with some of it’s own. If you look in DB_Sql, you’ll see the variables above are empty. The subclass provides these values, and it is the subclass you will use to create your database objects. You can call all the methods of DB_Sql on MyDBClass, because it is merely an extension. Think of it as MyDBClass IS a DB_Sql object with added functionality and/or data.