Authorizing User Access
Writing PHP scripts to manage the authentication process allows for flexible authorization logic to be applied when processing a request. Authenticating a user successfully against a list or table of known users doesn't automatically authorize that user to access an application. For example, an application might apply restrictions based on group membership: a user belonging to the DIRECTORS group gets to see the reports from the budget database, while others can't. The number of schemes for restricting access is limited only by a developer's imagination or more often by that of the marketing department. A user of a subscription-based service might supply a correct username and password, but be denied access when a fee is 14 days overdue. Access might be denied on Thursday evenings when system maintenance is performed. Implementing such authorization schemes requires designing the appropriate user table or tables.
There are several HTTP status codes that are appropriate to use when denying access to a user. Earlier, we used the response code of 401 Unauthorized to control HTTP authentication. The response status code of 403 Forbidden is appropriate if an explanation as to why access has been denied is required. Example 9-5 uses the code of 403 Forbidden. The HTTP/1.1 standard describes 17 4xx status codes that have various meanings. The infamous 404 Not Found is returned by Apache if the requested resource doesn't exist, and a PHP script can return this code if the exact reason for the refusal needs to be hidden. The code 402 Payment Required has been included, but the HTTP standard has not provided an interpretation of how it should be used.