Well, i kinda like to call a spade a spade in my code, because it helps me immensely to sort out what's going on conceptually. I realized awhile back that i could be doing the same with the role mechanism in CFMX, but in reality, the code needed is so simple there's no reason not to write it.
As a personal preference, i appreciate very much not needing to translate the concept in my head everytime i run across a part of the UI or a function that needs a permissionKey. I've got enough to keep track of in my mind as it is. And using a misnamed variable has led me astray many a time. So by now, i take great care in naming my variables and objects. To me, Role might be used to determine a set of keys for a user, adding another level of abstraction if needed. But in my experience, it's ALWAYS happened in even the smallest apps that a user with a certain Role needed a permission that happened to be in a different Role. So even in the case when you use Role to determine a set of permissionKeys, i'd build it into the app to be able to assign a Key independent of Role. :) n. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Adam Churvis Sent: Saturday, August 14, 2004 4:22 AM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] How smart should objects be? Nando, It seems like the keys in your security model map to roles in the MX security framework, and the locks map to tests for IsUserInRole() that determine whether or not the user is in a role (has a permission key). It sounds like the only difference might be one of granularity; "permissions" tend to describe many individual things a user may do, while "roles" tend to describe a set of permissions that a person serving in a role might need to have in order to accomplish that role's job. Am I seeing your model correctly? Have you worked much with the MX security framework? I'd be interested to hear your thoughts. It seems like lots of folks don't really use it in favor of the code they brought with them from CF5 and earlier days. Respectfully, Adam Phillip Churvis Member of Team Macromedia Advanced Intensive Training: * C# & ASP.NET for ColdFusion Developers * ColdFusion MX Master Class * Advanced Development with CFMX and SQL Server 2000 http://www.ColdFusionTraining.com Download CommerceBlocks V2.1 and LoRCAT from http://www.ProductivityEnhancement.com The ColdFusion MX Bible is in bookstores now! ----- Original Message ----- From: "Nando" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, August 13, 2004 10:02 PM 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 :) ---------------------------------------------------------- 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]
