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]
