22 Jul
2011
22 Jul
'11
9:22 a.m.
Philippe implemented a capabilities (ACL) based security model. It
worked very well, but IMHO was too complicated to setup properly and
use (due to the complete freedom).
Security is currently based on commands, something like create value
links or edit verbatim text does not really fit into that model. What
you could easily do however is to create a restricted edit command
that doesn't allow to edit these elements. This would follow the
pattern of 'edit page' and 'settings page' (earlier on everything was
in 'edit page').
Lukas
On Friday, 22 July 2011, Nick Ager <nick.ager(a)gmail.com> wrote:
Hi,
I can understand how the current implementation of Pier security could work well in the
case of a set of users each with their own sub-tree - a little like Unix's
'/home/user1' '/home/user2' etc, where users can control the commands
allowed to be executed on their sub-trees.
However I'm looking for a more capability model, for example:* does the user have
permission to see this view in wiki mode? * does the user have permission to create
verbatim html?
* does the user have permission to create value links?* etc
Is there a sensible way to map this onto the current security implementation? I've
currently mapped it with code like:
editorConfiguration allowWikiTextEditing: ((self context command:
PRWikiTextEditingCommand new) isValid).
This works however the owner/group/other structure permissions mapping seems too coarse
grained. I'd like to be able to have groups relating to these permissions then add
groups to users, depending upon the permissions I'd like to assign to them. Am I
looking at this in the wrong way? Is there a mechanism to support a capability model?
Cheers
Nick
--
Lukas Renggli
www.lukas-renggli.ch