RE: [CFCDev] How smart should objects be?

[Scott Barnes]

Hmm,   Thought I'd take a stab at this one and float a concept I've either picked up along the lines or cherry picked.   When dealing with security on most apps, dynamic permissions are the kiss of death. In that, if you don't constrain them UI wise, it could underpin your entire security model quite easily.   Roles to me are a set of individual specific tasks, carried out within an object or all objects. To me they should still be considered dynamic, as management and other stake holders have this habit of changing the scope 2 months into a project ever so slightly (that or your planning had a flaw - won't go into perfection vs. project management).   I liked one concept in that, an object has a "can" method(s) associated to it, one that looks after itself. An example is:   BankObject - canWithdraw() - canDeposit() - canPayPalFromAccount() - canXYZ()   (Please Note: If you prefer arguments passed in, cool, if not, cool... whatever blows your hair back).   The purpose of this, is you kind of ask the object "can I do this? yes/no" within that object is were you get the information (whether that be via a database, another object or interrogate your session scope). This concept kind of treats a security as a series of turnkeys (on/off) for specific permissions related to each "DataObject".   To wrap these up so that user doesn't have to assign permission after permission to another user, we could typically use a group. Inside your model, you can assign some already made groups and just simply say "hey for this user, look to group X for your perm". The moment they break away from that group and into their own, you pretty much clone the group but assign itself as a different entity. Then if the user wants to go back to the group, you can via the UI use an inherit concept (basically low level, delete me and put me back in the mainstream group).   The problem with this concept is, it kind of relies on persisting your object? in that to get a permission for every request. Typically you would instantiate an object of this type either once a request or once via a shared scope and leave it at that. Then within your code your code where you assign the (can see or not) you'd use an IF statement (eg: cfif <BankObject.canDeposit()>do stuff</cfif>).     One thing I also have considered with the Roles attribute assigned to a CFC, is simple basic low level roles. In that, if for some reason your object gets used outside your applications scope, you kind of need to have a basic safety catch and simply ask the questions (can this user update? can this user delete or can this user insert data?) so you could float the concept of putting a role "IsInsertFriendly" for all "add/create" methods you have, just in case (ignore naming conventions - just illustrating).   I had thought once of assigning roles within the CFC's themselves, but the downside to these are you have to do some crystal ball readings, in that think about all your potential user roles, and hardcode them to each method. If the time comes and you want to add more or worse, remove them (maybe they have a tangible reason to remove?) then code maintainability could be a tedious exercise? Its probably no different in many ways of assigning the "can" methods but at least these are specific to the context of that application. Plus i have enough debates over what to name a method, let alone thinking up "role names" that are universal enough to all objects.   This approach isn't abstract either and its how you execute it maybe your fall over? i.e. do you ask the question first, then allow the user to carry out the request? or do you carry out the request, unknown to the user you ask the question privately, and then throw an exception back saying "hey sorry you don't have permission".   We rely on exceptions & errors a lot in our framework, as we use a presenter as our "model' wrapper, and interrogate all errors to see if they are exceptions or actual errors and carryout workflow accordingly.   Its not for everyone and some projects the above has no chance of ever winning, but it seems ok concept and works well on a few occasions? Just floating it is all.     Regards Scott Barnes Senior Web Developer Alpha Business Systems [EMAIL PROTECTED] 1/31 Thompson St Bowen Hills QLD 4006 Ph +61 07 3216 0999 http://www.alphabus.com.au   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marlon Moyer Sent: Saturday, 14 August 2004 9:54 AM To: [EMAIL PROTECTED] Subject: [CFCDev] How smart should objects be? I have an object (company) that contains all the pertinent information/methods for viewing/updating a company profile.  Some users are only allowed to view the profile while others are given the ability to modify the information.  Should the company object accept a user object that contains permissions and roles and allows actions based on it, or should I have a security object that would call the company object?    I guess what I’m getting at is where do you put your security?  Does it make sense to embed it into objects or does that make it too complex?     Marlon