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.
Next: Logging In >>
More PHP Articles
More By The Disenchanted Developer, (c) Melonfire
