Your security service should be published, though perhaps via a reduced-functionality facade, because your controller will need some access information to properly render the UI. You don't want to go putting 'add document' or 'delete user' links in the UI if the user doesn't have the ability to actually do those things, so the UI layer needs to be able to retrieve that information from the application somehow.
I've found that that pretty much requires full access the security object, at least for data recall operations. For that reason, my security service doesn't have any methods that "do" anything; it's 100% data recall and logic, no actions. The objects for setting up users, defining permissions, etc. are separate, and that way I can expose my security service component directly as part of the public API of the app. cheers, barneyb On Thu, 10 Mar 2005 16:27:02 -0500, David Ross <[EMAIL PROTECTED]> wrote: > barney is spot-on... your sevices interact with each other behind the > "published" API that controller(s) or other calling code may use. Your > authz service might not even be publically exposed at all. > > -Dave Ross -- 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]
