For my
two cents, I don't think security should be enforced at the object level - the
object should be used by its context and should have no knowledge of it. I
would think that a cleaner approach would be to enforce security at the
controller level - there is where the ability to change a model would be
enforced.
If
you're using Flex within a Fusebox app - the movie has its own state discrete
from the HTML front end and therefore would manage its own security via the
backend objects it is using to interact with the model. Potentially the
same CFC security model could be used for both apps. All you're doing
is securing a resource. The only thing you wouldn't have with Flash is the
ability to call methods directly on the CFCs - you'd need analogous objects in
Flex/Flash to handle your security permissions that would be created after the
user's security profile was transferred from CF.
Jeff
---------------------------------------------------------- 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]-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Chastain
Sent: Thursday, March 10, 2005 1:46 PM
To: [email protected]
Subject: [CFCDev] OO Security for the OO PuristsThere has been some discussion recently about implementing security for an OO application and Roland posted his method this morning which I am personally very appreciative of. It is always nice to see an example. The security scheme I am needing to implement is very similar to the one Roland posted, so this is background info.----------To perform an action upon a given object, I have to have the right to perform that action as well as access or permission to the object I want to perform the action upon. For example, just because a sales rep. has the right to create proposals and permission to do so for his company does not mean he has permission to create proposals for another company. In the same sense just because a support engineer has permission to access the server room does not give then the right to change the configuration of a server.---------------------------------------------------------- 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]So, for every action in the application, the following checks need to be done:- Does the user have the right to perform the given action? (create proposal)- Does the user have permission to perform the given action on this object? (company 123)----------The question is, where are these checks performed as the answers to the follow questions point in different directions ...- A user knows what his/her rights are, so it should be the one to state if it has a given right?user.checkUserRight( 'create proposal' ):boolean- Who better knows what rights are required for a given action than the object those actions are being performed on, so that means that an individual object should be the one asking the user if it has a given right?document object is passed a user object and calls the checkUserRight( 'create proposal' ) on that user- An object has an access control list, so it should be the one to state if a user has access to it?object.checkAccess( user ):booleanBut, from an OO design standpoint, does all of this not put to much responsibility in the user and object to know about security?On the flip side, all of this logic could be moved to the controller, but .... what if I want to put an HTML interface and a Flex interface on an application? The HTML interface could use a Fusebox controller, but the Flex interface would access the objects via web services. So now, I am managing security in an Fusebox controller and in a Flex controller and if something needed changing (i.e. a right for a given method), I would have to find and change it in multiple places, so this is no good either.Also, as components are basically an API, should the application that utilizes the API have to know about security or should the API handle that?So, are there significant design or reusability issues in going one path (internal object security) vs. another (security in the controller), or is there another path all together? I am just about to the point of saying there is no right answer and flipping a coin. Anybody else want to chime in?Thanks-- Jeff
