I certainly see your point. My thinking here is that my Security object _might_ later do other things then interact with a user. It might interact with a web service request later as well.

Even if it didn't, it seemed appropriate to me that my Security object know the criteria for a User to have access, but that my User object should know that. Then I could use the same User object in a different site with a different Security object (if I can ever figure out how to set up my objects appropriately).

At 05:04 PM 4/28/2004 +0000, you wrote:
Right on, I think you are going the right direction.

Although I'm still unsure if a seperate security.cfc is necessary. Afterall the methods in the security.cfc pertain to only a user. CheckLogin() and login() preform actions for a user. I would put checkLogin() in the user.cfc and in your pages uses <cfif userObj.checkLogin()> for your logic. Or set it directly to a SESSION variable like SESSION.isLoggedIn = userObj.checkLogin().

As far as modularity, if security.cfc relies completely on user.cfc, then security.cfc is not modular at all and might as well be wrapped into the user.cfc.

my 2 cents

-adam

----------------------------------------------------------
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]

Reply via email to