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
Creating the Central Authentication Database Before you can use the login and logout applications, you need to create the central authentication database and then add a user to it. The central authentication data- base information is stored in both login.conf and logout.conf files using the following configuration variables: $AUTH_DB_TYPE = ‘mysql’; $AUTH_DB_HOST = ‘localhost’; $AUTH_DB_NAME = ‘auth’; $AUTH_DB_TBL = ‘users’; $AUTH_DB_USERNAME = ‘root’; $AUTH_DB_PASSWD = ‘foobar’; In our example, the database type is mysql and the database host name is local- host , which means we’re implementing the database on the same server as a MySQL database. If you want to use a different database host or a different database server such as Postgres or Oracle, you have to change these variables. For our example, I assume that you’re using the given sample values for $AUTH_DB_TYPE, $AUTH_DB_HOST, $AUTH_DB_NAME, and $AUTH_DB_TBL. However, I strongly suggest that you use different $AUTH_DB_USERNAME and $AUTH_DB_PASSWD values for your database. Make sure that the user you specify in $AUTH_DB_USERNAME has the privi- lege to access (select, insert, update,and delete) $AUTH_DB_NAME on $AUTH_DB_HOST. You should test the user’s ability to access this data- base using your standard database-access tools. For example, if you’re using MySQL, you can run the command-line MySQL client as mysql -u root -p -D auth to access the authentication database. Assuming that you’re using the given settings, you can create a MySQL database called auth using the mysqladmin create auth command. You’ll require appro- priate permission to run mysqladmin or equivalent commands to create the auth database. Please consult your MySQL documentation for details. Now to create the $AUTH_DB_TBL (users) table you can run the users.sql script using mysql -u AUTH_DB_USERNAME -p -D AUTH_DB_NAME < auth.sql com- mand. The auth.ddl script is shown in Listing 5-11. Listing 5-11: auth.sql # phpMyAdmin MySQL-Dump # version 2.2.5 # http://phpwizard.net/phpMyAdmin/ 146 Part II: Developing Intranet Solutions 08 549669 ch05.qxd 4/4/03 9:24 AM Page 146 # http://phpmyadmin.sourceforge.net/ (download page) # # Host: localhost # Generation Time: May 14, 2002 at 01:55 PM # Server version: 3.23.35 # PHP Version: 4.1.0 # Database : `auth` # # # Table structure for table `users` # CREATE TABLE users ( UID int(11) NOT NULL auto_increment, EMAIL varchar(32) NOT NULL default ‘’, PASSWORD varchar(128) NOT NULL default ‘’, ACTIVE tinyint(4) NOT NULL default ‘0’, TYPE tinyint(4) NOT NULL default ‘0’, PRIMARY KEY (UID), UNIQUE KEY EMAIL (EMAIL) ) TYPE=MyISAM COMMENT=’User Authentication Table’; The table created using this script is described in Table 5-3. TABLE 5-3 THE USER TABLE FIELDS Field Details UID This is the user ID field. This is automatically generated. EMAIL This is the username field. We use e-mail as the username in the login because e-mail is easy to remember and always unique for each person in an organization. PASSWORD This is the encrypted password. ACTIVE This is the active (1 or 0) field. If the value is 1, then the user is active and can log in. Otherwise, she cannot log in. TYPE The type of user is specified using this field. The type can be a number. Currently, we assume that the number 9 is the highest- ranking user, such as the administrator. After this table is created, you can add a user, as explained in the following sec- tion, to test your login/logout applications. Chapter 5: Central Authentication System 147 08 549669 ch05.qxd 4/4/03 9:24 AM Page 147 Testing Central Login and Logout To test the authentication system, you need to create users in the database. (User management applications are discussed Chapter 6.) To create a user using the MySQL command-line tool you can run commands such as the following: mysql -u root -p -D auth; Enter password: ***** mysql> insert into users (EMAIL, PASSWORD, ACTIVE, TYPE) values(‘admin@example.com’, ENCRYPT(‘mysecret’), 1, 9); Here the first line tells mysql to connect you to the auth database using user- name root and a password which you have to enter when asked. Of course if you are not using root account for this database, you should replace the username as appropriate. Next at the mysql prompt, you can enter an INSERT statement as shown. Here the insert statement creates a user account called admin@example.com with pass- word mysecret. You should change both the username and password to what you desire. The ACTIVE field is set to 1 to turn on the user and TYPE field is set to 9 to make this user an administrator. To create a regular user the TYPE field has to be set to 1. The insert statement inserts a user named “admin@example.com” with a pass- word called “mysecret” and sets the user’s status to active. The user type is set to 9, which is the highest-ranking user type. If you want to create new users using this script, then you have to change the username and password and run the script to produce the insert statement. After the user is added in the database you can run the login application from a Web browser. For example, Figure 5-7 shows the login application being called using the http://intranet.evoknow.com/php/login/login.php URL. Figure 5-7: The login application menu. 148 Part II: Developing Intranet Solutions 08 549669 ch05.qxd 4/4/03 9:24 AM Page 148 Enter the newly created username and password and log in. If you cannot login, check to see if the user exists in the authentication database. Also, if the user is not active, the user cannot log in. You can check whether the active flag is working by toggling it using update statements such as follows from your MySQL database command line. The following code shows a MySQL command-line session, which sets the active flag to 0 (ACTIVE = 0) and again activates the admin user (ACTIVE = 1 ). $ mysql -u AUTH_DB_USERNAME -p -D AUTH_DB_NAME mysql> update users set ACTIVE = 0 where USERNAME = ‘admin@example.com’; mysql> exit; $ mysql -u AUTH_DB_USERNAME -p -D AUTH_DB_NAME mysql> update users set ACTIVE = 1 where USERNAME = ‘admin@example.com’; mysql> exit; You can test the logout application by simply calling it directly using the appro- priate URL. For example, http://intranet.evoknow.com/php/logout/logout.php will log out a user session. Making Persistent Logins in Web Server Farms Organizations with Web server farms will have to use site-wide persistent logins to ensure that users are not required to log in from one system to another. Figure 5-8 shows a typical Web server farm. Figure 5-8: A typical Web server farm balances an organization’s server workload. Web Server 1 Web Server 2 Load Balancer Web Server 3 Web Server n Chapter 5: Central Authentication System 149 08 549669 ch05.qxd 4/4/03 9:24 AM Page 149 Web server farms are often used to increase scalability and redundancy for the application services the organization provides. Such a farm usually implements all the applications in each server node so that any one of the servers can go down or become busy at any time but the user is directed to a server that is able to service the application request. In such an environment, the session data cannot be stored in local files in each server node. Figure 5-9 shows what happens when file-based user sessions are used in a Web server farm. Figure 5-9: Why file-based sessions are not persistent in Web server farms. When a user logs into a system using a file-based session, the file is stored in a single server and, in the next request, the user might be sent to a different server due to load or server failure. In such a case the next system will not have access to the session and will simply redirect the user to the login application to create a new login session. This can annoy and inconvenience the user, so a central database- based session solution is needed, which is shown in Figure 5-10. To implement this solution, we need to define seven session management func- tions that PHP will use to implement sessions. The functions are session_open(), sess_close(), sess_read(), sess_write(), sess_destroy(), sess_gc(), and session_set_save_handler(). The sess_open() function is called to start the session, the sess_close() function called when ses- sion is closed, the sess_read() function is called to read the session information, the sess_destroy() function is called when session is to be destroyed, the sess_gc() function is called when garbage collection needs to be done, and finally session_set_save_hander() is used to tell PHP the names of the other six session functions. Web Server 1 Web Server 2 Load Balancer Any Request for Application X User request for application X Web Server 3 Web Server n 1st Request 2nd Request nth Request Session File Session File Session File 150 Part II: Developing Intranet Solutions 08 549669 ch05.qxd 4/4/03 9:24 AM Page 150 . auth.sql # phpMyAdmin MySQL-Dump # version 2.2.5 # http://phpwizard.net/phpMyAdmin/ 146 Part II: Developing Intranet Solutions 08 549669 ch05.qxd 4/4/03 9:24 AM Page 146 # http://phpmyadmin.sourceforge.net/. Figure 5-7 shows the login application being called using the http://intranet.evoknow.com /php/ login/login .php URL. Figure 5-7: The login application menu. 148 Part II: Developing Intranet Solutions 08. calling it directly using the appro- priate URL. For example, http://intranet.evoknow.com /php/ logout/logout .php will log out a user session. Making Persistent Logins in Web Server Farms Organizations