[Coefficient-devel] re-implementing the security model in coefficient

[Dylan E. <de...@cs...>]

I know there are not a lot of developers on this mailing list but I feel
as if the decisions effecting coefficient should be taken in a more open
environment and at least have some record of the reasoning behind them.
Therefore, this email. 
 
We have started another round of development on coefficient which is
driven by the business need of a re-implementation of the dgroups
project (http://www.dgroups.org). This release is focusing on cleaning
up some look & feel, fixing some bugs, make projects more robust, and
trying to make coefficient easier to use as a platform. 
 
The one place coefficient absolutely is terrible at is the way security
and roles are handled. At the moment all modules know explicitly about
the roles which are very hard coded into the system. If you want to use
coefficient for another purpose and you have different role requirements
you are pretty much out of luck and the existing modules become useless
as well because of their heavy dependancy on the hard-coded roles. 
 
We have been discussing revamping coefficient with a very loosly coupled
permission mechanism that will keep information in the DB but be totally
configurable. The modules should then only have to know about a simple
call, something like: SecurityService.canDoForPermission(user,
permission, object) where object is not required. A drawback to this is
that the configuration will not be trivial. 
 
Does anyone have any thoughts or imputs on this topic? Keep in mind that
we need to know things like: can a  user see a specific instance of an
object (project member), what actions can a user execute in relation to
given objects (can a user create a file on a project), etc... 
 
Dylan 

Dylan Etkin
ISTC
+27 12 841 3200



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.