RE: [CFCDev] OO Security?

[Roland Collins]

We intentionally put the security in the objects themselves for several reasons:   It greatly simplifies the API, which is used not only internally, but for web services as well.  Instead of having to have the end-user perform any access checks, and _then_ use the desired object/function, all the end user has to do is make the desired invocation and it is all handled for them.   It provides very fine-tuned granularity.  Each method in the object can (and frequently does) have different access rights than other methods.  For instance, some objects can have typical CRUD type functions, and each of these can have different permissions associated with them.  Who better to know what security is required for an operation, than the operation itself?   There is no way to circumvent the security in our system.  If you’re relying on the page/controller to authenticate the user, then there is the potential that the security can be circumvented by simply not making the security checks and calling the objects directly.   I should also mention that the better part of our business logic is contained in stored procedures, so a typical method is really nothing more than an access check and then a stored procedure call.  In essence, our CF objects are really just a wrapper for our true business objects, which are stored procedures.   Roland         From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of GroupOne Dev. Sent: Tuesday, March 08, 2005 1:39 PM To: CFCDev@cfczone.org Subject: RE: [CFCDev] OO Security?   Now that I say this however, I am back to questioning whether this functionality should be in the object itself or on the controller?  Should an object be tied this tightly to the authentication manager and the user or user group objects?  Or, should the document object strictly know about document stuff and leave authentication to the controller since that does not specifically relate to a document? Thanks -- Jeff From: "GroupOne Dev." <[EMAIL PROTECTED]> Sent: Tuesday, March 08, 2005 12:33 PM To: CFCDev@cfczone.org Subject: RE: [CFCDev] OO Security? This is along the lines of what I was saying.  However, it goes one step further by refactoring and pulling that common functionality out of each object and putting it in a central place which is always a good thing. One question - what is the user token?  Could the authentication manager not check for a user's session?  If the session variable does not exist, they are not logged in.  If the session variable does exist, but they don't have the right 'right', then an exception is thrown.  Or, does this token do something else? Thanks -- Jeff From: "Roland Collins" <[EMAIL PROTECTED]> Sent: Tuesday, March 08, 2005 11:49 AM To: CFCDev@cfczone.org Subject: RE: [CFCDev] OO Security? All of our objects require a user token to be passed in and they then perform their own access checks using our Authentication manager component.  The authentication manager throws an “AuthenticationException” if the user does not have the appropriate level of access, and this gets logged, kicked to our error handler, or whatever else we need to do. It winds up looking like this (in broken code, anyway).   <cfobject name=”SomeObject”>   <cffunction name=”getAccountBalance”>             <cfargument name=”userToken”>             <cfargument name=”accountNumber”>               <cfset var accountBalance = 0>               <cfinvoke component=”AuthenticationManager” method=”checkUserAccess”>                         <cfinvokeargument name=”userToken” value=”#arguments.userToken#”>                         <cfinvokeargument name=”requiredRight” value=”NameOfRequiredRight”>             </cfinvoke>                         <cfdotheprocessinghere>               <cfreturn accountBalance> </cffunction>     </cfobject>   HTH, Roland   ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org