Apache Notes ============ This package allows you to create a complex site authorization system where specific actions on resources are given custom rules. It extends Apache::AuthCookie to track sessions. It has been tested with Apache 1 and 2, and seems to work well. There are sample sites in the samples directory. The differences in the two apache environments require slightly different setups, so be sure to use the proper sample for your configuration. Use Apache2::SiteControl for apache 2.x. Description =========== There are two levels of control in Apache::SiteControl. The first is managed by Apache::SiteControl, and determines if a valid user has logged in. If so, it makes a user object available to the request processor. This is done using Apache::SiteControl::UserFactory (a good base implementation is already written). The underlying code associates this user with a session, and manages the browser interaction. The second level of control is supplied by an application level PermissionManager. The user objects are passed to this object, along with the requested action and an opaque resource (of any type). Rules are installed in the PM that determine if a specific action is allowed for a given user and resource. if($manager->can($currentUser, "change", $dnsrecord)) { ... } where the PM applies the various installed rules (user-defined) and returns true if the action is allowed, false otherwise. In this example, one of the rules might detect that the resource (dnsrecord) is a row from a DNS tracking table. It might then check to see if the currentUser is associated with DNS management and return true if they are, false otherwise. The top level application could then use this in a pretty abstract way. For example, if there is a generic section of code that allows users to modify a row from a table, the same code could be used: if($manager->can($currentUser, "change", $thisRecord)) { ... } The application doesn't have to figure out what thisRecord is...the rules can sense them. This allows the top-level application to be written in very generic terms, and rules to be written based on the actual logic involved. A rule might include code like this: sub grants { $this = shift; $user = shift; $action = shift; $resource = shift; if($action eq "change") { if($resource->isa("DNS::Record")) { if($resource->getContactEMail() eq $user->getAttribute("email")) { return "permission granted by DNSRule"; } } } return 0; } which would detect the proper types that it knows how to handle, and do a check that would indicate if permission is to be granted. Comments on Rules How would you make a system that allows everything, unless something is specifically denied? Have a GrantAll rule that always grants permission. Add rules that never grant, but deny on specific cases. How to make a system that denies everything except things that have been checked out: Write rules that grant on your specific cases. The default is to deny permission if no rules have anything else to say about the request. A rule can take several approaches: Relative rule: It grants but never denies. Or it denies, but never grants. Absolute rule: If it grants, then it does not deny. If it does not grant, then it denies. Read the manual pages for more information.