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]
