User Authentication With Apache And PHP - Hidden Costs (
Page 4 of 11 )
The process outlined on the
previous page works very well, and should satisfy your need for basic security
in a Web application or on a Web site, especially if you're not looking for
anything too complicated. However, this simplicity comes at a price.
If
you're relying on Apache to handle user authentication for you, you're forced to
use the process outlined on the previous page. You're stuck with the Apache way
of doing things, and cannot alter the data source used for user verification
(for example, an SQL database or a file containing data in a different
format).
So, if you're working on a legacy system which already has user
information in a different format, using Apache's HTTP authentication is
probably not a good idea, since integrating the two authentication schemes will
involve:
- converting, or migrating, the existing user database to an
Apache-compliant format. This may require you to keep two copies of the same
data (and update both whenever either one changes) or port legacy code over to
use the new format. Both options are difficult, time-consuming and
sub-optimal.
- using two different authentication schemes, one for Apache
and one for the prior legacy system. This is user-unfriendly, since it requires
every user to remember two usernames and passwords, and also makes your
application difficult to maintain or upgrade in future.
- hacking the
Apache source code to use the user information from the legacy system instead of
its own format. If you have the time, patience and QA personnel for this
development effort, great. If not, this option is probably unacceptably
complicated.
Another important limitation with Apache's HTTP
authentication feature is the lack of control over the graphical user interface
displayed for login. HTTP authentication works by having the server send
"HTTP/1.0 404 Unauthorized" headers to the browser, and relying on the browser
to respond by popping up an appropriate GUI for login. Most of the time, this
GUI takes the form of a system dialog box, with fields for user name and
password. Since this dialog box is internally generated by the browser, it
cannot be customized or altered in any way.
When designing custom,
branded Web applications or products, this lack of control is typically deemed
unacceptable. Most of the time, it's considered preferable to have a login GUI
that fits in with the look and feel of the application, and that can be
customized to the customer or user's requirements.
This does not mean
that HTTP authentication via Apache is bad. It simply means that it may not fit
every situation. In case it fits your specific needs, great - you can stop
reading right now and catch a few winks. In case it doesn't, keep reading for an
alternative approach.
/ 57 
