(which actually began with v3.x and has been updated ever since - so a
complete overhaul is long overdue) to a object-leaning CFC-based setup.
Note I say "object leaning" because I'm not trying to recreate any major
pattern or do everything in OO - I'm trying to keep the best aspects of
procedural code, but move the foundational elements into CFCs. So far it's
been going great - I'm extremely pleased with what I've got so far.
Basically there are now a bunch of CFCs: three of them mirror CF's view of
the world so I've got a DP_Application.cfc (application settings, DSNs,
etc), DP_Session.cfc (Session information) and a DP_Request.cfc
(page/request specific stuff like current paths and settings). I've also
done CFCs (and DAO components) for Clickstreaming, Agent (browser)
Information and Navigation.
Like I said - so far I'm very pleased.
But now I'm trying to convert my security system over. The data-side of the
system is as simple as can be. The usual three tables: Users, Groups and
Users2Groups. In the users table I've got a number of fields for use with
the security system itself (password hash, userID, login dates, number of
logins, etc) and a very large number of fields to cover personal information
(name, various addresses and phone numbers, IM IDs, email preferences, etc).
As you can guess each page can be restricted to certain groups, users can
belong to multiple groups, etc.
Anyway - what I'm trying to do now is determine how to do convert security.
Anybody done this and want to share?
My current thinking is that there are many functions specific to application
security - things like authenticating, adding/editing/removing groups, etc.
I've started putting them into a "DP_Security.cfc" which will be loaded as a
property of the DP_Application.cfc (I could have put them inside it, but it
was already getting a little long).
Then there are a bunch of things that are user-level: putting a user into a
group, updating passwords, getting personal information, etc. So I've
created a "DP_User.cfc" that would contain all the information about the
user and be cached as a property of DP_Session.cfc (in the session scope).
However I'm hung up on the particulars.
If a populated user's component means you've logged in, what should indicate
no log in? An empty component? A component that hasn't been inited or no
users component at all?
Should the security system, when authenticating, return the user object or
just the UserKey and let the user object populate itself?
In the end I want to easily say "isLoggedIn()" or "isAdmin()" or
"isEntitled()" - preferably from the session-based user component. But at
the same time it seems odd to me that a single set of DB tables has multiple
components operating on them.
As I said I'm converting this code over so it all works (but right now is
decentralized in several custom tags, the login templates, etc) so I know
how to deal with data and I've got the actual security concepts down pat -
it's the OO aspects that have me stumped.
Any words of wisdom?
Thanks,
Jim Davis
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
