#native_company# #native_desc#

Session Management and Authentication with PHPLIB Page 2

By Chad Cunningham
on July 30, 2000

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


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.