Secure PHP Development- P19 ppt

Restrict access to sensitive applications When you have an application that should be used by only a restricted set of users, you need to control access to the application from either PH

See your errors before someone else does

Often malicious hackers use debugging or error information to take advantage of a broken application This is why it is critical that you perform extensive tests on your Web applications before you deploy it on production servers

The best way to test and find problems is to have all levels of error reporting enabled using the error_reporting(E_ALL) function This function should be used as the very first line in your application code For example:

<?php // Enable all error reporting error_reporting(E_ALL)

// Your code goes below.

?>

During development you should set error_reporting() to E_ALL, which enables all types of errors to be reported There are many error reporting levels You can find all about these error reporting levels in http://www.php.net/manual/en/

ref.errorfunc.php#errorfunc.constants

Once you have thoroughly tested your application, you can reduce the error reporting level or even disable it However, if you do the latter, make sure you enable error logging using the error_log() function You can learn about this function at http://www.php.net/manual/en/function.error-log.php

Restrict access to sensitive applications

When you have an application that should be used by only a restricted set of users, you need to control access to the application from either PHP code or using Web server access control mechanism This is covered in great detail in Chapter 22

Best Practices for Source Configuration Management

When developing any software, use a version-control system to manage changes

We used Concurrent Version System (CVS) when developing applications discussed

in this book CVS allows you to create versions of your software by creating a source repository from which you check out and check in code changes CVS main-tains all version information automatically so that you can retrieve an older

Chapter 3: PHP Best Practices 61

version with a single command It is also the de-facto version control mechanism for many large-scale Open Source software

You can learn more about CVS at www.gnu.org/software/cvs or at

http://www.cvshome.org.

Summary

In this chapter I have discussed various best practices for functions/methods, data-base, user interface, documentation, security, and version control Getting used to these best practices is often very difficult since many programmers are often under great time pressure to produce workable applications However, it is very important

to get started with these practices as early in the development as possible so that they become second nature in future projects This is particularly true for getting used to version control tools such as CVS Many developers find version control as

an “additional task” that does not relate directly to the deadline and simply wait till the very end to place code in version control This type of practices often leads to big code maintenance problem in the long run The key issue is early adoption of best practices so that you get used to it from the beginning

62 Part I: Designing PHP Applications

Developing Intranet Solutions

CHAPTER 4

Architecture of an Intranet Application

CHAPTER 5

Central Authentication System

CHAPTER 6

Central User Management System

CHAPTER 7

Intranet System

CHAPTER 8

Intranet Simple Document Publisher

CHAPTER 9

Intranet Contact Manager

CHAPTER 10

Intranet Calendar Manager

CHAPTER 11

Internet Resource Manager

CHAPTER 12

Online Help System

Part II

Chapter 4

Architecture of an Intranet Application

I NTRANET APPLICATIONS ARE PRIMARILY focused on automating an organization’s daily business processes A modern company has many intranet applications that are available to its employees to help them be more productive and efficient For example, a group calendar system or task-tracking system can save a great deal of time and resources for most companies with more than five employees This chap-ter focuses on the underlying architecture of intranet applications and discusses an open-source framework that enables you to develop intranet PHP applications in a rapid manner

Understanding Intranet Requirements

To develop intranet applications, you need to understand how a typical intranet is deployed A company with two employees can have an intranet, but the average intranet application is deployed in an organization with tens to hundreds of users

Figure 4-1 shows how an intranet “connects” employees in multiple departments of

a company that uses an intranet application server to manage its daily internal business functions

A company generally uses its intranet server to automate interdepartment com-munication activities such as a shared calendar, shared contact database, document management, project/task tracking, and so forth

Before you develop the framework that will enable you to create intranet appli-cations in PHP, you need to understand the intranet user requirements Figure 4-2 shows how a single department within an organization appears from an intranet-requirements point of view

Users in organizations work in teams A team usually has a team leader and a project assignment The projects are managed by the department head This type of hierarchical user base is very common in modern organizations

65