If you are trying to simplify the API (which does not sound bad at all), does the calling app still not need to know about users in order to pass the user object or the user's id value into the API method call? This sounds like at least this level of security (whether the user is logged in) is pulled out of the API and into the controller either way.
Having the object or the method know what rights are required does make sense and that is probably why Macromedia added the 'roles' attribute to the <cffunction tag. The problem is that while this could allow for automatic checking of roles/rights, it does not allow for checking of permissions ... just because you have the right to create a document, do you have permission to do it here? So, there would still have to be some logic either in the controller or the method to do this check.
All I wanted was one definitive answer .... of couse I cannot remember when I last got one when talking oo programming.
Thanks
-- Jeff
From: "Roland Collins" <[EMAIL PROTECTED]>
Sent: Tuesday, March 08, 2005 1:21 PM
To: [email protected]
Subject: RE: [CFCDev] OO Security?
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:
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:
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:
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
