This is the project homepage for the Request Handler Design Pattern.

The Request Handler design pattern is simple procedural style logic for basic, abstract request handling. This can be used in scripts hacked up in minutes or in full out MVC applications. This logic may seem obvious but it's certainly not implemented with any kind of regularity that I have found. This pattern lends itself to simple functions, which can be mapped easily to methods, or perhaps simply code executed straight through.

Please note that we're not describing a general "good practice" application design here. We're not describing the "general flow" of an application. It is very important to realize that we are looking very closely at the singular incoming request to the application and that single request's life span from coming in to being fulfilled. Such a request might be a "change password" request.

This design pattern helps an application handle requests and the most obvious case is a web-based application receiving requests like a normal website would. The design pattern is four simple steps:

1. Authenticate
2. Validate
3. Authorize
4. Perform

In detail, the steps are defined as such:

1. Authenticate
   • Here, we authenticate the user as the type of user we expect, they have a valid session, and any other fundamental requirements needed to perform the operation requested
   • It's important to note, we do not determine here if this user type has any other access - simply that the fundamental requirements of a user making a request of our system are satisfied
   • This authentication may in fact be optional if you simply don't care (apps with logins will certainly want this)
   • Some validation is done here to ensure things like incoming IDs, Sesssion IDs, cookies, etc. are valid and can be handled safely
     • This is a necessary side-effect of not wanting to do full-blown validation in order to simply authenticate
2. Validate
   • In this step, we validate all incoming data that will be used to perform the requested operation
   • By validating things like length, character sets, data types, size, etc, we ensure that the actual performing of the operation will not fail because of bad, unexpected or malicious data
3. Authorize
   • Authorization is different from authentication. In authentication, we already know we have a valid user, user type, session, if applicable, and any other requirements needed to gain access to the system. As such, in authorization we determine if the user type actually has the privileges needed to execute the requested operation
   • In a simplistic system, there may be no logic to pass through this part. In a complicated system with granular access privileges, this area is vital to the safe operation of the system
   • It's important to note that authorization may require some input from the user and so it comes after validation
4. Perform
   • In this stage, all requirements to perform the requested operation are completely satisfied
   • We know the user is a valid user, their session is valid, and any other requirements are valid for authentication
   • We know the user's input is good and will not cause problems for this stage because we've designed this stage to handle a specific range of input and validation was a success
   • We know the user is authorized to perform the requested operation
   • Thus, we can perform the operation without any worries or other checks (besides checks integral to performing the operation itself)

As you can see, this is a very abstract set of ideas and it allows you to implement it in any way you'd like. Procedural, object oriented, or otherwise. It's simply a good rule set to follow.

Please consider donating any amount if you've found any of my code useful.

• N/A

• N/A

• N/A

• N/A

To contact me, please email .