Marlon, While i'm at it ... i had another thing to add. If the KEY part of your permission situation varies as a User is using the application, based on some criteria that is dynamically determined, then you may have a good case for needing to encapsulate a PermissionKeyManager to assign keys (or key states, true/false, that's how i do it) to users. I could imagine a game for instance, and if you accumlate enough points, you get the key to enter another section. Or maybe keys are assigned based on roles, and when a role gets added to your profile by a user admin, a real person, the PermissionKeyManager assigns you the keys for that role. PermissionKeyManager's responsibilty lies in knowing what keys get assigned for a certain role.
But if the permission requirements of your app are such that the "Permission Key Manager" is a real person, an admin, and i think many/most apps fit in that category, then your permissionKeyRing lives very nicely in your app as an attribute of User. (First rule of OO, encapsulate what varies). Unless you wanna go OO-overboard and make yourself a permissionKeyRing object just to carry the keys for a user around. Ok, then a User has a KeyRing, pass it into your User object when you create it, and get the keys from there on each request. You could also make a separate table for KeyRing, and associate them with the userID - but what's the point. This concept of "encapsulate what varies" has helped me a lot to sort out object model scenarios. PERMISSION and SECURITY seem like such important concepts to an application, it's easy to assume that they, of course, need to be encapsulated in an object. But when you get down to it, if they don't vary, basically i *think* we're fine just leaving permissionKey(s) as an attribute of User. So in my mind, it's not how smart an object should be, but "does the thing vary within my application" that's the determining factor. Debate is welcome! Now lemme get another glass of Bardolino. Somehow it tastes very fine this evening. n. :) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Nando Sent: Saturday, August 14, 2004 4:03 AM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] How smart should objects be? Marlon, I'm a big fan of permission based security, and found that a lot of fuzzy thinking cleared up when i got my head around this approach. There are 2 aspects to consider, the KEY and the LOCK. Any process or any part of the UI that needs to be secure has a "lock" (an if statement) like a door has a lock, and users run around with a set of keys (mine are in a structure, let's call it permissionKey for clarity's sake). If your users are running around your app encapsulated in user objects, then when they login, they get their permissionKey ring and it gets stored as a struct in the variables scope of user. Then a simple call to session.myUser.getPermissionKeys() at the beginning of the request will sort the UI stuff out right nice. Inside another object, you'll need to pass either the userObj or the permissionKeyRing in, your choice. At the moment in my apps, permissionKey is just an attribute of user. An admin assigns the keys when the user is created, and the user's permissionKey ring is persisted (in my case, as a wddx in a DB field.) Simple The other half, the lock part, seems like it *should* be some object somewhere, but in practice, it's probably just hardcoded into your app here and there. If you need the LOCK part variablized and hence encapsulated (first rule of OO, encapsulate what varies, if the LOCKS don't vary much, hardcode them) - then you might have to put your OO thinking cap on and go at it. But I think in most apps it's apparent ahead of time what needs security and what doesn't. Does that help? Anyone else wanna discuss / debate this after hours? nando :) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Barney Boisvert Sent: Saturday, August 14, 2004 2:14 AM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] How smart should objects be? That should be higher up than your business objects themselves. Obviously security is part of your business logic, but the use of the information (allowing pages to load, displaying certain links, etc) is mostly a UI concern, and should stay there. An exception would be if you're using the CFLOGIN framework, or any kind of integrated framework that'll do the horrible nasty work of tracking user information across the layers of your application in a way that doesn't break encapsulation all over the place. I personally don't use the CFLOGIN framework, but that decision was greatly influenced by the fact that I already had a robust permission-based security system in place. If you're into having method level security (rather than something tied to the UI), it's definitely the way to go. cheers, barneyb ----- Original Message ----- From: Marlon Moyer <[EMAIL PROTECTED]> Date: Fri, 13 Aug 2004 18:54:05 -0500 Subject: [CFCDev] How smart should objects be? To: [EMAIL PROTECTED] 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 -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.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' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.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' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
