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/FTP/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
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
