A couple of people asked for the code to my CFC security system - here it is:
ftp://ftp.depressedpress.com/DP_Security.zip There are two folders: 1) cfc_DepressedPress: To run the test scripts you'll need to set up a mapping (sorry, but I gave up trying to work around it and still maintain a decent file structure and access). The mapping should be "cfc_DepressedPress" and point to the "cfc_DepressedPress" folder. Other than that this folder can be placed anywhere. 2) Web: These files should be placed in a web directory. I've created a test "site" to see the system in (fairly unimpressive) action. To use it you must: 1) Create the cfc_DepressedPress mapping described above. 2) Create a DSN to an updatable SQL Server Database (Access or even other DBs might work, but I've not tested them). 3) You must edit the persistence entity instances to match your DB. These are in "\DepressedPress\Web\Test\Application.cfm" (line 19) and "\DepressedPress\Web\Install\Install.cfm" (line 6). Take a look at "\cfc_DepressedPress\Utility\DP_PersistenceInfo_DSN.cfc" for the parameters. 4) The "Web\Install" folder contains the script that creates the data tables for the system. You can examine the "\cfc_DepressedPress\Security\DP_SecurityConfiguration.cfc" template to see the changes made. This install process also creates an initial user with a user name of "administrator" and a password of (wait for it!) "password". This user is given access to the "Member" and the "Administrator" groups. The Test site presents a very simplified implementation. One page requires log in while another requires membership in the "Administrator" group. There's a simplified login page and this should all work. It uses the application scope. Also included is a file called "\Web\Test\RandomSampleCode.cfm" - this contains a whole bunch of snippets for working with the system. It assumes (for the most part) the same storage and set up as the sample application. Conceptually I've defined a few things: Group: An umbrella label for protected things/function (or sets of things/functions) such as "Adminstrator", "Member", "Editor", etc. User: A virtual concept representing a person (or, I guess, something else maybe) using the system. Each user has an associated Credential, Profile and Entitlement. Credential: User information specific to the security system (username, password hash, last login date, etc). Profile: User information not specific to the security system (name, phone number, address, etc). Entitlement: A list of groups that the user can access. Authentication: A representation of a "current log in". Contains references to the user, the session which authenticated and times of access. The "\cfc_DepressedPress\Security\" Package consists of the following (the rest of the CFCs are required but are general utility or framework materials and not specific to security): +) DP_SecurityConfiguration.CFC This CFC just contains basic installation and uninstallation routines (creation of data tables, scheduled tasks, etc). It's only used for installation (and installation). +) DP_Security.CFC The main entry point of the whole shebang. Contains system settings, creation/deletion methods (for users and groups), and authentication methods. Also contains the Authentications collection and the mediator (caching) components (described below). +) DP_Authentications.CFC A collection component for holding/managing authentications. Contains methods for retrieving specific authentications (using sessionkey) and expiring timed-out sessions. +) DP_Authentication.CFC Represents a current authentication and is keyed from SessionID. Contains the UserKey (which links an authentication to a user) and the ability to fetch and return that user's Credential, Profile or entitlement from the mediators. Also contains the time of last access (used to control authentication time-outs). The authentication component could also be extended to manage a "three-strikes and you're out" rule by limited any specific session to three login attempts. +) DP_Credential.CFC Represents a credential. Takes a UserKey and has methods for loading and saving Credential data from the database. All system users have to have a Credential. +) DP_Profile.CFC Represents a profile. Takes a UserKey and has methods for loading and saving Profile data from the database. Profiles are optional (not all system users have to have a profile). So a "blank" profile can be returned. +) DP_Entitlement.CFC Represents an entitlement. Takes a UserKey and has methods for loading and saving Entitlement data from the database. Entitlements are optional (since not all system user have to have access to something). This also what's called to check entitlements (as in isEntitled(grouplist) ). +) DP_CredentialMediator.CFC All requests for Credentials will go through the CredentialMediator. It will determine if the requested Credential exists (returning an error if it doesn't) and return a reference to the component instance. The component instance will be placed in a collection cache. In this way requests for the same credential will also result in the passing of the same instance reference meaning that any changes made will be instantly applicable to all users of the instance. It will also have methods to manage this cache (clearCache(), expireCache() and so forth ) +) DP_ProfileMediator.CFC Same as the CredentialMediator only for profiles. Also if a Profile is requested that doesn't exist this will first ensure that a credential exists before sending a blank profile (otherwise an error will be thrown). +) DP_EntitlementMediator.CFC Same as the ProfileMediator, except managing Entitlements. In addition there are the "DB_" files. These contain all the persistence-layer stuff. The basic files in "\cfc_DepressedPress\Security\DB_" are sort-of "Interfaces" that define the methods needed by the brokers (but aren't functional themselves). The "\cfc_DepressedPress\Security\DB_SQLServer2000" are the actual, functional templates for MS SQL Server. As I said those brokers might work with other DBs (there's nothing SQL Specific so far as I know). But if you want to create new ones you can use those as templates. Create a new folder with name format "DB_NewDatabaseName" and put all the new brokers there. You can then change the persistence calls (from step 3 of the set up) to use the new name (without the "DB_"). The system will automatically use the new brokers. I'm sure there's a hundred useful things I'm missing (and someday I'll actually get this system properly documented) but for now I hope that will do it. Let me know if you have any questions or (gasp!) find any bugs. I've been using this system on several public sites for a while, but it's hardly gone through what you could call exhaustive testing. Jim Davis ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
