>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).
This isn't a bad way to do things depending on your particular situation. If you have to do things like checking roles and other security-related stuff pretty frequently, using a single CFC for all that functionality might fit the bill. Particularly if you're doing something like putting a user CFC in your session, having another CFC that contains all your security related methods and having that interact with the user CFC in your session can work quite well. Since you said you didn't want to get too deep into design patterns, etc. I'll leave out the discussion of how you'd probably *really* want to do the interaction between the security CFC and the session user CFC ...
>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?
There are any number of ways to handle this. In a recent project I used a session facade pattern for my user, and in essence this does end up creating an empty user object in the session scope if you check something like user.getEmail() and there is no object present. Depending on how you implement things you might have to do an IsDefined() on your user CFC *and* check for the existence of data like a user's role id or whatever.
>Should the security system, when authenticating, return the user object or
>just the UserKey and let the user object populate itself?
There are numerous design patterns to help with all of this as well, but basically if you're talking about the log in process itself, what I would do it check for a valid login, get data back about that user, populate your user object, and put that in your session. Personally I'd have the security CFC (or however you implement this) either return a populated user object to the caller or just handle all the steps above 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.
You might need to elaborate on this a bit. If by "from the session-based user component" you literally mean that the user CFC would have methods in it like isEntitled(), I wouldn't do that. I'd have my security CFC interact with the session user object (preferably via a facacde). In my mind the user CFC should just have information about the user, and you would do authentication, etc. via another CFC whose only job is to do those sorts of things.
Hope that helps--feel free to follow up with me on any of this. I'm always very glad to see people using CFCs and OO more!
Matt
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
