>> Confusion sets in when people start using roles for things other than roles, like a
>> collection of permissions. When you become granular down to the point of
>> individual permissions, you start losing the concept of a true role, and instead
>> have to manage a handful (or more) of individual permissions.
yes. we have unfortunatly found this the hard way. the difficulty is that we model the
"lock 'n' key" in a silimar way to windows 2000 file permissions - groups AND ad-hoc
permissions. Our users admins set it themselves and it's only education ("please use
roles!") that prevents it being a real mess.
>> The whole permission/anti-permission model reminds me of the hellish days of Novell
>> NetWare 3.11's security model with its "Negative Rights Mask."
we don't allow "blocking" - you either have permission or you don't. you are never
denied
>> I'm concerned with, it's situations where Emp A can edit 10 of 20 records.
Marlon, we are also. our security model is still being "worked on" so this may be an
issue with us. time will tell...
a cumblesome way of chcking if a user can edit a specific record sounds like it has to
be part of the method call as a lookup.
A QUESTION: how do you know whether a user can edit a specific record? they can edit
record 10 but not 11. How do you capture who can do what for a specific record? when
someone enters new data, is there a "can only be edited by admin and Fred" setting?
>> This is why I'm thinking the object should be intelligent about who can do what to
>> each record....
that makes sence. For us, we've got a "presenter" object that controls page flow. this
is where we'll probably put the permission/access logic, not directly in the page (as
it is at present - it works but it can't do additional lookups without effort).
but the thought of getting a record and then checking some value of it to see whether
the current user can edit it seems very painful. luckily, our "people" data are broken
into entities and the permissions are assigned per entity.
is there any simpler way of doing this (without re-building db tables, etc)?
ADDITIONAL: to tie this into a thread from a couple of days ago: Aspect Oriented
Programming: one aspect that *seems* to be popular with AOP is security and
permissions.
ie: you build your app with methods to get, display and save data. but you overlay the
access to those methods with another layer of code (java in this case). The two are
completly seperated. the CF-based "aspect" just does data and is unaware of the other.
the Java aspect just allows access to the methods triggered by the CF methods called
(well this is the theory anyway).
- and yes, I can see some real stuff-up with doing something like this...
just 2cents worth
barry.b
--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
----------------------------------------------------------
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]
