I think you're pretty close. Your hunch about user.login() was correct. I'd put your login method in your security CFC, since it's not a user function, it's a security function that's being performed. The method would return true or false whether the login was successful. If false, just go back to the form. If true, set some marker (I use session.authenticated) to indicate that the session has been authenticated, and do whatever other setup you need (such as instantiating the user cfc into the session scope).
Always keep in mind that you don't want CFCs interacting with any scopes except their own internal instance variables and arguments passed to methods. As soon as you reference any external scope from within a CFC, that CFC instantly becomes much less reusable. However, it's generally a desirable thing to instantiate CFCs INTO shared scopes. That way all their instance variables are, in effect, members of that scope, so you get caching and such. Just be careful with locking and all the usual concerns with shared scopes. Once you get to doing web services (if you have stateful, multi-request services), then you can reuse everything. You probably won't be storing a user CFC in the session scope, and you might not use the session scope at all, but your checkLogin method in security.cfc will be identical, you'll just deal with the boolean result differently. Cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Steve Bryant > Sent: Wednesday, April 28, 2004 7:54 AM > To: [EMAIL PROTECTED] > Subject: [CFCDev] CFC interaction (user log in) > > As I am sure that my question will reveal, I am pretty new to CFCs. > > I have toyed with CFCs, but this is my first attempt to use them in > production. The site needs some separation between logic and > presentation > and may eventually need to serve web services. > > I have a Security.cfc (that is actually called from a root-level > System.cfc). I also have a Session-scoped User.cfc. > > I am trying to figure out the "correct" way to handle a > login. My first > thought was to have my login handled by my Security.cfc which > would in turn > call Session.User.Login() if successful. > > That feels wrong, but I can't quite figure out what would be right. > > Should I have a User.CheckLogin() action that would call out to the > Security.cfc? If so, do I call out to > Application.System.Security.CheckLogin()? That still seems > wrong (although > I am not sure why). The only other approach that comes to > mind is to invoke > the CFC directly, but that seems pretty wasteful since it is > already in memory. > > What am I missing? Is my whole approach in need of > re-evaluation or am I > just missing a small piece? > > Any help would be greatly appreciated. > > Thanks! > > Steve > > ---------------------------------------------------------- > 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] > ---------------------------------------------------------- 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]
