[Sorry for those also on CF-Talk - I posted this there as well.] A coupla weeks ago I posted on CF-Talk about how to build a decent portable, CFC-based security system. The original thread was here:
http://www.houseoffusion.com/cf_lists/messages.cfm/threadid=33981 <http://www.houseoffusion.com/cf_lists/messages.cfm/threadid=33981&forumid=4 > &forumid=4 In that thread I explained my plans and concepts. Since then I've gone ahead the built the thing. A zip of the system and some test scripts is here: ftp://ftp.depressedpress.com/DP_Security.zip This system should be considered REALLY, REALLY BETA! 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. Right now the only database supported is MS SQL Server 2000 (although 7.0 should also work - heck, I didn't do any MS-specific code that I know of so a lot of DBs might work, but the only thing I've used is SQL Server 2000). To actually use it you should take a look at the test files (they assume, but this can be changed, a datasource called "test" which can be written to) and run the "TestSecurity_Install.cfm" template to create the data tables. The system (when done) will be open source and published for free at www.depressedpress.com <http://www.depressedpress.com/> Some of the features I'm rather proud of: 1) The system has intelligent caches for all components - you pass references to these caches, not data. This means that changes made to the information take effect for everybody using the information immediately (not "next login"). 2) The system defines database "broker" components which, in theory, should make it quite easy to add database support (or any persistence layer really: flat files, XML, LDAP, etc). You just extend the existing Broker templates and create only the DB-specific code (most of while is really simple). 3) The system holds user specific information in three component types: "Credentials" store system information about the user (like password hash, userID, login count, etc), "Profiles" store personal information (name, address, phone numbers, etc) and "Entitlements" store group access information. Each of these objects is cached separately and each can be easily extended to add more properties or validation rules (the actual CFCs used to define each are dynamically determined at install time and can be changed later). 4) The system doesn't assume or need session scope access - rather you pass it some session identifier and use it as your link into the system. The system itself (because of the caching) works best if you cache it, but it can be cached in the Application or Server scopes (or in the Session scope for that matter, but I'm not sure why you'd want to). The main things missing from the system (aside from extensive testing!) are methods to work with system information from an admin perspective (things like "getAllUsers()"). Most of these will end up in the Users.CFC. The system also doesn't have an interface, but that was by design (I want the system to be pluggable into pretty much any CF application). When it's released I hope to have at least one complete sample interface for admin functions and end-user functions. I'd love feedback on this and really love any testing you might do. Thanks in advance, 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]
