The controller, as far as I (the app developer) am concerned can do whatever the heck it wants. I'm going to develop my app to be secure. However, I'd hope that the UI developer (who writes the controller), leverages the security service that I exposed as part of my app's API to help make the UI 'smoother' for users, by checking permissions and the like so that only the appropriate actions are available for a given user.
I don't think that making the security calls from my service objects is anything like asking the user if they can do a given thing, primarily because I'm not asking the user. Of course, I might be indirectly, but that's an implementation detail of the service object, not a fundemental axiom of the application design. That decoupling is why I like it with the extra layer in the mix. The user is the one with the data needed to make the decision, but it shouldn't know how to make that decision, because it's not in charge. On Thu, 10 Mar 2005 13:41:20 -0600, Jeff Chastain <[EMAIL PROTECTED]> wrote: > > One additional question on this approach ... who makes the calls to the > security service? Does the controller make the calls and therefore it needs > to know what rights are necessary for each method and without the controller > the app is generally un-secure? The other option I see is putting the calls > to the security service back into the objects, but then things are right > back where they started. > > Sounds to me that in order to keep the objects as pure as possible, the > controller is going to have to be pretty smart one way or the other. > > -- Jeff -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 invites. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
