This is the simplest PHP authentication to implement but has the problem of being limited on flexibility
and high on maintenance cost. It literally places the username and password into the script as seen in the
following example:
<?php
if (($_SERVER['PHP_AUTH_USER'] != 'root') ||
($_SERVER['PHP_AUTH_PW'] != 'training')) {
header('WWW-authenticate: Basic Realm="Photo Album"');
header('HTTP/1.0 401 Unauthorized');
print "You must provide a valid username and password!";
exit;
}
// Remainder of script
?>
In this example, the first portion of the script reads in the username and password variables. If the variables
do not match the hard-coded user name or password, then the script prints out some HTTP header
information and text saying that the username and/or password was not valid. It then exits the script and
terminates the rest of the script processing. If, though, the username and password are correct, this portion
of the script is ignored and the remainder of the script is executed.
Limitations of Hard-Coding
Although this method is quick and easy, it has a number of drawback that make it unrealistic for
applications in production.
• Using the same username - As the code stands, every user requiring access to this web page would
need to use the same login name and password. This is not the way most applications in production
work. The majority of applications in production use the username to provide specific preferences
and specific access to resources that could not be done if everyone is using the same username. Of
course, additional usernames and passwords could be coded in, but that is just nonsensical and leads
to poor coding techniques.
• Maintenance nightmare - If the username and password are compromised, a new username and
password have to be hard-coded in and everyone using that username and password have to be
notified of the change. Anytime that code has to be touched leads to the greater likelihood that
something else could be inadvertently changed causing the script to malfunction. Avoiding touching
code in production is a best practice for reliability of services.
and high on maintenance cost. It literally places the username and password into the script as seen in the
following example:
<?php
if (($_SERVER['PHP_AUTH_USER'] != 'root') ||
($_SERVER['PHP_AUTH_PW'] != 'training')) {
header('WWW-authenticate: Basic Realm="Photo Album"');
header('HTTP/1.0 401 Unauthorized');
print "You must provide a valid username and password!";
exit;
}
// Remainder of script
?>
In this example, the first portion of the script reads in the username and password variables. If the variables
do not match the hard-coded user name or password, then the script prints out some HTTP header
information and text saying that the username and/or password was not valid. It then exits the script and
terminates the rest of the script processing. If, though, the username and password are correct, this portion
of the script is ignored and the remainder of the script is executed.
Limitations of Hard-Coding
Although this method is quick and easy, it has a number of drawback that make it unrealistic for
applications in production.
• Using the same username - As the code stands, every user requiring access to this web page would
need to use the same login name and password. This is not the way most applications in production
work. The majority of applications in production use the username to provide specific preferences
and specific access to resources that could not be done if everyone is using the same username. Of
course, additional usernames and passwords could be coded in, but that is just nonsensical and leads
to poor coding techniques.
• Maintenance nightmare - If the username and password are compromised, a new username and
password have to be hard-coded in and everyone using that username and password have to be
notified of the change. Anytime that code has to be touched leads to the greater likelihood that
something else could be inadvertently changed causing the script to malfunction. Avoiding touching
code in production is a best practice for reliability of services.
Comments
Post a Comment