Chapter 2: Understanding and Avoiding Security Risks
Identifying the Sources of Risk
Minimizing User-Input Risks
Not Revealing Sensitive Information
Summary
Chapter 3: PHP Best Practices
Best Practices for Naming Variables and Functions
Best Practices for Function/Method
Best Practices for Database
Best Practices for User Interface
Best Practices for Documentation
Best Practices for Web Security
Best Practices for Source Configuration Management
Summary
Part II
Chapter 4: Architecture of an Intranet Application
Understanding Intranet Requirements
Building an Intranet Application Framework
Creating a Database Abstraction Class
Creating an Error Handler Class
Creating a Built-In Debugger Class
Creating an Abstract Application Class
Creating a Sample Application
Summary
Chapter 5: Central Authentication System
How the System Works
Creating an Authentication Class
Creating the Central Login Application
Creating the Central Logout Application
Creating the Central Authentication Database
Testing Central Login and Logout
Making Persistent Logins in Web Server Farms
Summary
Chapter 6: Central User Management System
Identifying the Functionality Requirements
Creating a User Class
User Interface Templates
Creating a User Administration Application
Creating a User Password Application
Creating a Forgotten-Password Recovery Application
Summary
Chapter 7: Intranet System
Identifying Functionality Requirements
Designing the Database
Designing and Implementing the Intranet Classes
Setting Up Application Configuration Files
Setting Up the Application Templates
Intranet Home Application
Installing Intranet Applications from the CD- ROM
Testing the Intranet Home Application
Summary
Chapter 8: Intranet Simple Document Publisher
Identifying the Functionality Requirements
The Prerequisites
Designing the Database
The Intranet Document Application Classes
Setting up Application Configuration Files
Setting Up the Application Templates
The Document Publisher Application
Installing Intranet Document Application
Testing Intranet Document Application
Summary
Chapter 9: Intranet Contact Manager
Functionality Requirements
Understanding Prerequisites
The Database
The Intranet Contact Manager Application Classes
The Application Configuration Files
The Application Templates
The Contact Category Manager Application
The Contact Manager Application
Installing Intranet Contract Manager
Testing Contract Manager
Summary
Chapter 10: Intranet Calendar Manager
Identifying Functionality Requirements
Understanding Prerequisites
Designing the Database
The Intranet Calendar Application Event Class
The Application Configuration Files
The Application Templates
The Calendar Manager Application
The Calendar Event Manager Application
Installing the Event Calendar on Your Intranet
Testing the Event Calendar
Summary
Chapter 11: Internet Resource Manager
Functionality Requirements
Understanding the Prerequisites
Designing the Database
Designing and Implementing the Internet Resource Manager Application Classes
Creating Application Configuration Files
Creating Application Templates
Creating a Category Manager Application
Creating a Resource Manager Application
Creating a Resource Tracking Application
Creating a Search Manager Application
Installing an IRM on Your Intranet
Testing IRM
Security Concerns
Summary
Chapter 12: Online Help System
Functionality Requirements
Understanding the Prerequisites
Designing and Implementing the Help Application Classes
Creating Application Configuration Files
Creating Application Templates
Creating the Help Indexing Application
Creating the Help Application
Installing Help Applications
Testing the Help System
Security Considerations
Summary
Part III
Chapter 13: Tell-a-Friend System
Functionality Requirements
Understanding Prerequisites
Designing the Database
Designing and Implementing the Tell- a- Friend Application Classes
Creating Application Configuration Files
Creating Application Templates
Creating the Tell-a-Friend Main Menu Manager Application
Creating a Tell-a-Friend Form Manager Application
Creating a Tell-a-Friend Message Manager Application
Creating a Tell-a-Friend Form Processor Application
Creating a Tell-a-Friend Subscriber Application
Creating a Tell-a-Friend Reporter Application
Installing a Tell-a-Friend System
Testing the Tell-a-Friend System
Security Considerations
Summary
Chapter 14: E-mail Survey System
Functionality Requirements
Architecture of the Survey System
Designing the Database
Designing and Implementing the Survey Classes
Designing and Implementing the Survey Applications
Developing Survey Execution Manager
Setting Up the Central Survey Configuration File
Setting Up the Interface Template Files
Testing the Survey System
Security Considerations
Summary
Chapter 15: E-campaign System
Features of an E-campaign System
Architecting an E-campaign System
Designing an E-campaign Database
Understanding Customer Database Requirements
Designing E-campaign Classes
Creating Common Configuration and Resource Files
Creating Interface Template Files
Creating an E-campaign User Interface Application
Creating a List Manager Application
Creating a URL Manager Application
Creating a Message Manager Application
Creating a Campaign Manager Application
Creating a Campaign Execution Application
Creating a URL Tracking and Redirection Application
Creating an Unsubscription Tracking Application
Creating a Campaign Reporting Application
Testing the E-Campaign System
Security Considerations
Summary
Part IV
Chapter 16: Command-Line PHP Utilities
Working with the Command-Line Interpreter
Building a Simple Reminder Tool
Building a Geo Location Finder Tool for IP
Building a Hard Disk Usage Monitoring Utility
Building a CPU Load Monitoring Utility
Summary
Chapter 17: Apache Virtual Host Maker
Understanding an Apache Virtual Host
Defining Configuration Tasks
Creating a Configuration Script
Developing makesite
Installing makesite on Your System
Testing makesite
Summary
Chapter 18: BIND Domain Manager
Features of makezone
Creating the Configuration File
Understanding makezone
Installing makezone
Testing makezone
Summary
Part V
Chapter 19: Web Forms Manager
Functionality Requirements
Understanding Prerequisites
Designing the Database
Designing and Implementing the Web Forms Manager Application Classes
Creating the Application Configuration Files
Creating Application Templates
Creating the Web Forms Submission Manager Application
Creating the Web Forms Reporter Application
Creating the CSV Data Exporter Application
Installing the Web Forms Manager
Testing the Web Forms Manager
Security Considerations
Summary
Chapter 20: Web Site Tools
Functionality Requirements
Understanding Prerequisites
Designing the Database
Designing and Implementing the Voting Tool Application Class
Creating the Application Configuration Files
Creating the Application Templates
Creating the Vote Application
Installing the Voting Tool
Testing the Voting Tool
Summary
Part VI
Chapter 21: Speeding Up PHP Applications
Benchmarking Your PHP Application
Buffering Your PHP Application Output
Compressing Your PHP Application Output
Caching Your PHP Applications
Summary
Chapter 22: Securing PHP Applications
Controlling Access to Your PHP Applications
Securely Uploading Files
Using Safe Database Access
Recommended php.ini Settings for a Production Environment
Limiting File System Access for PHP Scripts
Running PHP Applications in Safe Mode
Summary
Part VII
Appendix A: What's on the CD-ROM
System Requirements
What's on the CD
Troubleshooting
Appendix B: PHP Primer
Object-Oriented PHP
Appendix C: MySQL Primer
Using MySQL from the Command- Line
Using phpMyAdmin to Manage MySQL Database
Appendix D: Linux Primer
Installing and Configuring Apache 2.0
Installing and Configuring MySQL Server
Installing and Configuring PHP for Apache 2.0
Common File/Directory Commands
Index
Wiley Publishing, Inc. End-User License Agreement
Nội dung
Method Description checkPassword() Checks the user-supplied new password. If the new password is empty, does not match the confirmation password, violates the minimum length limit, or matches the dummy password, it displays the appropriate alert message. change_pwd() This method is called by showScreen() to display the password-change interface. authorize() Checks if the current user is authorized to run the application. Because anyone can run this application, this method uses the isUser() method with a User object called $userObj to return TRUE or FALSE status accordingly. Listing 6-6 shows the user password application user_mngr_passwd.php. Listing 6-6: user_mngr_passwd.php <?php // Turn on all error reporting error_reporting(E_ALL); // If you have installed framewirk directory in // a different directory than // %DocumentRoot%/framework, change the setting below. $APP_FRAMEWORK_DIR=$_SERVER[‘DOCUMENT_ROOT’] . ‘/framework’; $PEAR =$_SERVER[‘DOCUMENT_ROOT’] . ‘/pear’; $PHPLIB =$_SERVER[‘DOCUMENT_ROOT’] . ‘/phplib’; // Insert the path in the PHP include_path so that PHP // looks for PEAR, PHPLIB and our application framework // classes in these directories ini_set( ‘include_path’, ‘:’ . $PEAR . ‘:’ . $PHPLIB . ‘:’ . $APP_FRAMEWORK_DIR . ‘:’ . ini_get(‘include_path’)); Continued Chapter 6: Central User Management System 191 09 549669 ch06.qxd 4/4/03 9:24 AM Page 191 Listing 6-6 (Continued) $AUTHENTICATION_URL = “/login/login.php”; $LOGOUT_URL = “/logout/logout.php”; $APP_MENU = ‘/home/home.php’; $APPLICATION_NAME = ‘USER_MNGR’; $XMAILER_ID = ‘Example User Manager Version 1.0’; $DEFAULT_LANGUAGE = ‘US’; $DEFAULT_DOMAIN = ‘example.com’; $ROOT_PATH = $_SERVER[‘DOCUMENT_ROOT’]; $REL_ROOT_PATH = ‘/user_mngr’; $REL_APP_PATH = $REL_ROOT_PATH . ‘/apps’; $TEMPLATE_DIR = $ROOT_PATH . $REL_APP_PATH . ‘/templates’; $CLASS_DIR = $ROOT_PATH . $REL_APP_PATH . ‘/class’; $REL_TEMPLATE_DIR = $REL_APP_PATH . ‘/templates/’; require_once “user_mngr.errors”; require_once “user_mngr.messages”; require_once ‘DB.php’; require_once $APP_FRAMEWORK_DIR . ‘/’ . ‘constants.php’; require_once $APP_FRAMEWORK_DIR . ‘/’ . $APPLICATION_CLASS; require_once $APP_FRAMEWORK_DIR . ‘/’ . $ERROR_HANDLER_CLASS; require_once $APP_FRAMEWORK_DIR . ‘/’ . $AUTHENTICATION_CLASS; require_once $APP_FRAMEWORK_DIR . ‘/’ . $DBI_CLASS; require_once $APP_FRAMEWORK_DIR . ‘/’ . $USER_CLASS; require_once $TEMPLATE_CLASS; $MIN_USERNAME_SIZE= 3; $MIN_PASSWORD_SIZE= 3; $DUMMY_PASSWD = ‘1234567890’; $ROOT_USER = ‘kabir@evoknow.com’; $SECRET = 916489; $CHAR_SET = ‘charset=iso-8859-1’; // Application names $USERMNGR_MNGR = ‘user_mngr.php’; $USERMNGR_FORGOTTEN_APP = ‘user_mngr_forgotten_pwd.php’; $USERMNGR_CHANGE_PWD_APP = ‘user_mngr_passwd.php’; 192 Part II: Developing Intranet Solutions 09 549669 ch06.qxd 4/4/03 9:24 AM Page 192 /* START TABLE NAMES */ $APP_DB_URL = ‘mysql://root:foobar@localhost/auth’; $AUTH_DB_TBL = ‘users’; /* END TABLE NAMES */ $STATUS_TEMPLATE = ‘usermngr_status.html’; $USERMNGR_MENU_TEMPLATE = ‘usermngr_menu.html’; $USERMNGR_USER_TEMPLATE = ‘usermngr_user_form.html’; $USERMNGR_PWD_REQUEST_TEMPLATE= ‘usermngr_forgotten_pwd.html’; $USERMNGR_PWD_EMAIL_TEMPLATE = ‘usermngr_forgotten_pwd_email.html’; $USERMNGR_PWD_RESET_TEMPLATE = ‘usermngr_pwd_reset.html’; $USERMNGR_PWD_CHANGE_TEMPLATE = ‘usermngr_pwd_change.html’; $ADMINISTRATIVE_USER = 9; $STANDARD_USER = 1; $USER_TYPE = array(‘9’ => ‘Administrator’, ‘1’ => ‘Standard User’); ?> This application can be run after a user is logged in to the system. Its interface is shown in Figure 6-4. Figure 6-4: Changing a user password. Chapter 6: Central User Management System 193 09 549669 ch06.qxd 4/4/03 9:24 AM Page 193 A user enters the new password in the Password field, confirms the new pass- word in the Password (confirm) field, and clicks the Change Pwd button to submit the change request. The user is shown a status message stating that the password has been changed. From the next login, she will be required to enter the new pass- word at the central login prompt. Creating a Forgotten-Password Recovery Application If Murphy were alive today, surely he would have added a new law about forgotten passwords in his famous “Murphy’s Laws” list. It would probably go something like the following: If a user is given a password, it will be forgotten. Passwords are often forgotten due to the “Remember my password” feature in many desktop applications — which caches the password for easy access, freeing the user from having to remember it — or because users have to try to remember several passwords, different ones for different applications. In our application architecture, each user needs to know a single password. Forgetting the password will be very annoying because the user will not be able to access any applications until the password is reset. Ideally, there should be a way for the user to recover the forgotten password. However, our central authentication system uses cryptographic (one-way hash) passwords, so there is no way for the system to determine what the original pass- word is if the user fails to supply the correct one. So instead of recovering the old password, we will allow the user to recover from the forgotten password state by replacing her forgotten password with a new one. Figure 6-5 shows a functional diagram of this recovery process. Here’s how the recovery process works: 1. The user tries to log in using the wrong password. 2. The central login application rejects the login attempt. 3. The user clicks the link to the forgotten-password recovery application and enters her e-mail address and clicks on Send Mail button. 4. The forgotten-password recovery application sends the user an e-mail that includes a URL. 5. The user clicks the URL and is taken to a password-change form, which she fills out using a new password. 6. The user submits the form. The application stores the new password and returns a success message. 7. The user can now log in using the new password. 194 Part II: Developing Intranet Solutions 09 549669 ch06.qxd 4/4/03 9:24 AM Page 194 Figure 6-5: A user recovering from the “forgotten password” state. In the following section, I discuss how to design, develop, and test a forgotten- password application that works with our central authentication framework. Designing the forgotten-password recovery application We know what we want the application to do, so now we need a flow diagram of the application, as shown in Figure 6-6. As the flowchart indicates, when the application is starts (Step 1), it gets an e-mail address from the user. If the e-mail address belongs to an existing user, the application sends an e-mail to the user with a URL that has embedded information to allow the user to call the same application. The embedded URL in the e-mail has step=2 set so that the application can determine which step is next. In Step 2 mode, the application verifies that the information supplied with the URL is valid and came from the e-mail sent earlier. It then allows the user to enter a new password. If the new password is acceptable — that is, it meets the minimum password size requirement — it is encrypted and stored in the database. Now let’s look at how you can implement this flow diagram into an application. Login App Authentication Request with Wrong Password Authentication Request Failed Enter New Password Password Changed Request to Recover from "Forgotten Password" Email with Link to Change Forgotten Password Forgotten Password App 6 5 4 7 3 2 1 Chapter 6: Central User Management System 195 09 549669 ch06.qxd 4/4/03 9:24 AM Page 195 . =$_SERVER[‘DOCUMENT_ROOT’] . ‘/pear’; $PHPLIB =$_SERVER[‘DOCUMENT_ROOT’] . ‘/phplib’; // Insert the path in the PHP include_path so that PHP // looks for PEAR, PHPLIB and our application framework //. accordingly. Listing 6-6 shows the user password application user_mngr_passwd .php. Listing 6-6: user_mngr_passwd .php < ?php // Turn on all error reporting error_reporting(E_ALL); // If you have. 191 Listing 6-6 (Continued) $AUTHENTICATION_URL = “/login/login .php ; $LOGOUT_URL = “/logout/logout .php ; $APP_MENU = ‘/home/home .php ; $APPLICATION_NAME = ‘USER_MNGR’; $XMAILER_ID = ‘Example User