This is actually almost exactly how our system works, it's just not as OO in that we're passing ids instead of objects. In fact, in our administrative functions, the sequence of events is nearly identical. :)
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Chastain Sent: Thursday, March 10, 2005 3:58 PM To: [email protected] Subject: RE: [CFCDev] OO Security for the OO Purists Interesting approach, I like it. I always picture the controller doing what you have the controller doing plus what you have the service layer doing which makes the controller have to do and know a lot more. This will definitely warrant some more investigation. Thanks -- Jeff -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert Sent: Thursday, March 10, 2005 2:43 PM To: [email protected] Subject: Re: [CFCDev] OO Security for the OO Purists Service methods. The methods that actually do something. controller gets a request for "postDocument.cfm?docID=4" and says: docService.postDocument(url.docID) docService says: secService.ensureAuthorized("post document"); doc = getDocumentById(url.docID); secService.ensureObjectAccess(doc, "post"); doc.post(); the secService.ensureAuthorized method exits normally if the current user is authorized to perform the specific action, but if they're not, it raises an exception (which the docService ignores, and therefore propogates to the UI to handle is it sees fit). The secService.ensureObjectAccess method does the same thing, except that it checks to ensure the current user has the specific access to the specific object (assuming here that the 'document' object is a subclass of some abstract 'controlledAccessObject' or whatever, and that's the type of the ensureObjectAccess method's argument). If neither of those checks raised an exception, it must be safe to proceed, so the post method of the document is called, and the method exits, since it's job is done. Like I said before, it's almost guarenteed that the secService uses user objects to perform it's duties, but the point is that the rest of the application doesn't need to care about it, because it's all encapsulated. So if you think about your point #3 from the application's perpective, it's correct (the app does security without thinking about users), so all three of your points are accurate. cheers, barneyb On Thu, 10 Mar 2005 14:04:32 -0600, Jeff Chastain <[EMAIL PROTECTED]> wrote: > > Maybe I am missing something here. > > 1. The controller can do whatever it wants - great. > 2. The app is secure without the controller - great. > 3. The user/object is decoupled from security - great. > > So, where does security go then? Who calls the security service > functions passing the user and object? > > -- 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] ---------------------------------------------------------- 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] ---------------------------------------------------------- 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]
