Abstracting What’s the Same PHP Help

Once again, you find yourself with some code in show_user.php. that probably doesn’t belong in show_user.php. Why is that? Because the same authorization and authentication you have in show_user.php. belongs in every other script that should require logging in, such as delete_user.php.  You don’t want to write that code over and over; it becomes just like other repeated code you now have in app_config.png and database You should take it out of individual scripts and place it somewhere that all your scripts can use.

Another Utility Script: authorize.php

Fire up your editor once more; this time, create a file called authorize.php. You can start by adding that valid user name/password combination:

define(VALID_USERNAME, “admin”);
define (VALID_PASSWORD, “super_secret”);
At this point. you’d usually write a function: maybe authorize or get_credentials or something like that. But is that really what you want? Do you want to have to require_once authorize. php, and then explicitly call a function?

More likely, you want to identify scripts that require authorization with a single line:

require_once “../scripts/authorize.php;”

Then, ideally, the authorization would all just magically happen for you.

Given that. you don’t want a function that has to be called. You just want some PHP code in the main part of authorize.php. That way, by requiring authorize.php, that code runs and handles authentication, and your script doesn’t have to do any thing to get the benefits of authentication and authorization.

In a lot of ways, authorization here is like having JavaScript inside a set of <script> tags with no function:
<script type=”text/javascript”>

As soon as a browser encounters that JavaScript, it runs it. The same is true of PHP outside of a function, so you can drop your authorization code right into

define(VALID_USERNAME, “admin”);
define (VALID_PASSWORD, “super_secret”);
if (!isset($_SERVER[‘PHP_AUTH_USER’]) II
!isset($_SERVER[‘PHP_AUTH_PW’]) II
header(‘HTTP/1.1 401 Unauthorized’);
header(‘WWW-Authenticate: Basic realm=”The Social Site”‘);
exit(“You need a valid username and password to be here. ”
“Move along, nothing to see.”);

Now, any script that has a require_once for authorize.php will cause authorize.php to be processed, which in turn will run the authorization code. That, in turn, will ensure that users are either logged in or are forced to log in. So, things look quite nice.

Remove this code from show_users.php and add a require_once for authorize.php.

require_once’ ../scripts/app_config.php’;
require_once’ /scripts/authorize.php’;
reuire_once ‘../scripts/database_connection.php’;
require_once’ ../scripts/view.php’;
// Authorization code is no longer in this script
// Build the SELECT statement
$select_users =
“SELECT user_id, first_name, last_name, email ..
FROM users”;
// and so on…

The next time you go to show_users.php you get a nice login dialog box. But. that’s not all this change buys you. Add a similar line into delete_users.php.

require_once’ ../scripts/app_config.php’;
require_once’ ./scripts/authorize.php’;
require_once’ ../scripts/database_connection.php’;
// and so on…

To test it out, close out your browser so that any passwords are lost. Then, open your browser again and navigate directly to delete.user.php. You’ll be greeted with a login dialog box (see Figure 12-6). What’s significant about this? Most obviously, all it took was a single line of PHP to add security to another page.



But there’s more! If you’ve logged in, close out your browser again and head over to show_users.php. As you’d expect, you need to log in. After you’ve logged in, click the Delete icon on one of your users. This will take you to delete_user.php, and the_.// PHP in authorize.php will be triggered. However, because you’ve already logged in to the realm identified as “The Social Site,” you’re not prompted to log in again.

Any page that uses this realm, in effect, shares credentials with other pages in the same realm. Because you logged in to access $.how_users.{Jhn, and that realm is identical to the realm for delete_users.php your delete request goes through without a problem. Figure 12-7 shows the result-no login dialog box in sight. There’s still a glaring problem, though. At this point, it’s easy to forget that behind every good script lies a great database. It’s a horrible idea to have a PHP script even a utility script like app_config.php or app_config.php contain a few constants defining allowable user names and passwords. Storing bits of information like this is the job of the database; hence the title of the next section.



Posted on January 12, 2016 in Authentication and Authorization

Share the Story

Back to Top
Share This