This three-page online tutorial/article talks
about managing user session and authentication using PHPLIB, a set of
PHP classes designed to make is easier to develop web based PHP
applications.
Session Management and Authentication with PHPLIB
Let's face it, web pages aren't designed for interaction with users. At one
time or another, you've probably found yourself needing to know what user
you are dealing with, and some information about that user. But how do you
do it on the web? There are many ways, but most of them are either error
prone, or serious security risks. Passing around form data from page to
page can easily be sniffed, and even more easily forged. What is a
webmaster to do?
Session Management and Authentication with PHPLIB
The simple answer isPHPLIB.
PHPLIB is a set of PHP classes that are
designed to make is easier to develop web based applications - things that
need interaction. This is provided by many classes, the most essential
being authentication, session management, permissions, and database
abstraction.
What You'll Need
To use phplib, you need php installed on your server. Unlike basic
authentication, phplib works with either the cgi or the module. You will
probably need at least version 3.0.5 of php. Earlier cgi versions may work
if you compiled them with --enable-foce-cgi-redirect option. Otherwise, you
will get nothing but security errors. PHP also needs to be configured with
track_vars enabled. You will also need a database. PHPLIB currently
supports MySQL, Orace, ODBC, PostgreSQL, and Sybase.
How it Works
First and foremost, the classes need to be configured for your system. The
only file that has to be modified is the local.inc file included in the
distribution. It is filled in with a sample setup which can be used almost
as is, or can be modified as you want. Before setting it up though, it's a
good idea to understand what is going on.
Each page that uses PHPLIB must first import all of the needed files. You
can do this with php's auto_prepend feature if you have access to your
php.ini and you want the files included on EVERY page. If not, you can
specify an include directory in the php.ini, or just use the absolute path
to require the PHPLIB files. A sample file called prepend.php3 is included
in the distribution, which can be required at the top of each file to
include all of the other needed files.
At the top of each phplib page, you must make a call to the page_open
function. This initializes the features that you plan on using, more on
this later. A typical page_open call that gives authentication, session,
and permission capabilities looks like:
<?php
page_open(array("sess" => "Cms_Session", "auth" => "Cms_Auth", "perm" => "Cms_Perm"));
?>
The keys of the array (sess, auth, perm) are the variable names you
will use to address the objects, and must be the standard variable names
phplib uses (sess, auth, perm...). The values are the names of the classes
you create in your local.inc. The page_open call must be before any output
to the browser, and you only need to put in the features that you are going
to use (if you're not using authentication on the page, just leave that
part out). The script must end with a call to the page_close() function,
which writes all changes back to the database. If you forget the
page_close() call, you may find some things not working quite as expected...
Because phplib uses cookies to store information, your page_open() call
must be issued before ANY output is sent to the browser. Output can be
anything from html to blank lines. If you find yourself getting errors
which say something along the lines of "Oops - SetCookie called after
header has been sent" this means that there was some output before the
page_open was called. The typical culprits, and the hardest to find, are
blank lines outside of the <? and ?> tags in the included files. Check
your local.inc or prepend.php3 for blank lines at the end with vi, or
another editor which will show you these.
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.
|
