> Does this suggest that if I know that I am going to use web > services later > (which I don't) that I should do all of my session tracking > in Application > scope to be consistent?
Actually, exactly to the contrary. You should rely on CF's builtin stuff as much as possible. In general, it's going to be more efficient, better implemented, and better tested than your own code. More to the point, if you abstract your business logic well, then the amount of code that is actually dependant on your interface will be very minimal. That gives you the luxury of building each interface with no intention of ever reusing ANY of it. Thus they can be built by different people, with different technologies, under different management, whatever, and you don't have to worry about it. Yes, you did just read me saying that you can build with no intention to reuse. Not to say that the code shouldn't be well structured, documented, and modular, but you shouldn't burden yourself with worrying about sharing code, because if you are, then you need to do some more abstraction. Cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Steve Bryant > Sent: Wednesday, April 28, 2004 3:06 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] CFC interaction (user log in) > > OK. I think I have it now. > > Between your comments and Nando's (thanks Nando), I think > that part of my > problem is that my User object was a bad idea from the start. > I do not, as > yet, have any need for such a thing. I need (at most) a > structure in my > Session scope to store authentication information. I looked > at User.cfc and > that was all it was doing or likely to do in the future. > > Does this suggest that if I know that I am going to use web > services later > (which I don't) that I should do all of my session tracking > in Application > scope to be consistent? > > How bad an idea is a Presenter.cfc? > > Thanks! > > Steve > > At 01:52 PM 4/28/2004 -0700, you wrote: > >The logic for determining whether a set of login credentials > is valid is > >business logic, but how you remember the answer is usually > tied to the > >presentation layer. You probably won't use session > variables if you're > >being called as a web service, but the validation is identical. > > > >Here's an example, that'll hopefully help. > > > >Say I've got a security CFC with a authenticate method that > accepts two > >strings: a username and a password, and returns a boolean > indicating whether > >the credentials are valid. In that same CFC is an addUser > method that takes > >a bunch of information and creates a new user. I'm not > saying that's a > >particularly good design, just setting the stage I need. > > > >Scenario #1: > > > >Martha is a web user, she comes to your site and wants to add a user. > > > >Request #1 > >Get the login form. She fills it out, and submits. > > > >Request #2 > >Your CF/HTML presentation layer gets the form fields, checks > to make sure > >they exist, have length, whatever, and passes them to your > security CFC's > >authenticate method. It returns true. The presentation layer sets a > >session variable (authenticated) to true, and creates an > instance of the > >User cfc contaiing Martha's information, and stores that in > session.user as > >well. Finally, it uses CFLOCATION to forward to the add user form. > > > >Request #3 > >The request for the form comes in, the presentation checks > to make sure > >session.authenticated exists, is boolean, and evaluates > true. Then is > >CFINCLUDEs the login form, which happens to use > session.user.getFirstName() > >to personalize the message little. That's sent to Martha, > she fills it out, > >and submits. > > > >Request #4 > >The presentation layer checks the make sure > session.authenticated is ok. > >Then it validates the form fields, and then calls the > addUser method on your > >security CFC. Finally, it CFLOCATIONs to a conformation > screen, passing the > >id of the newly created user. > > > >Request #5 > >The request for the confirmation screen comes in, the > presentation layer > >checks session.authenticated, and creates an instance of the > user CFC for > >the new user from the passed ID, and outputs a confirmation > to Martha, again > >personalized using session.user.getFirstName(). > > > >Scenario #2: > > > >Edith is a client who connects over web services to the same > application, > >using a third party (reseller) front end. We won't talk > about Edith, but > >rather the server (named johann) that is, in effect, > proxying to our web > >services. > > > >Johann calls the authenticate method of the securityproxy > web service, > >passing a username and password. The securityproxy cfc > calls authenticate > >on the security CFC which returns true. The securityproxy > uses an array in > >the application scope to track valid sessions. It creates a custom > >sessionID, adds it to the appliction scope array, and the > returns it to the > >invoker > > > >Johann calls the addUser method of the securityproxy web > services, passing > >the sessionID returned earlier and whatever other > information is needed. > >The securityproxy CFC validates the sessionID against the > application-scope > >array, checks the input parameters, and then calls addUser > on the security > >CFC to actually create the user. Finally, it returns the id > of the new user > >back to the invoker. > > > >Hopefully that illustrates the difference between the > presentation logic and > >the business logic. The security CFC didn't change, but > everything else > >did. The CF/HTML interface still used a session-scoped User > object, but the > >web services interface didn't need one. > > > >Yes, I admit that the example was somewhat contrived, but > not as much as you > >might think. > > > >Cheers, > >barneyb > > ---------------------------------------------------------- > 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]
