I forgot a couple of things, as it's quite early here. Brain no work.
The 'resource' column should be populated with '*' when you alter the
table.
I've only ported the Wiki to this permission system, ticket, browser,
etc. have not been touched, though the same concept applies to those.
trac-admin has been updated:
permission list [user]
permission add <user> <action>[:resource,...] [action] [...]
permission remove <user> <action>[:resource,...] [action] [...]
eg.
permission add
WIKI_VIEW:HowToContribute,RecentChanges,SandBox,TitleIndex,Trac*,WikiFormatting,WikiStart
permission remove WIKI_MODIFY WIKI_CREATE
Dunno whether this is the best syntax, but it works for now.
The API, as far as most plugins (except IPermissionStores) are
concerned, should be 100% backwards compatible, which is good. Plugins
and users can take advantage of the finer granularity if they wish, but
if they do nothing behaviour will be the same.
As an example of how this could be used, I envisaged an authz
IPermissionStore which could handle permissions for all elements of
trac:
[groups]
admins = cmlenz,jborg
devs = cmlenz,jborg,cboos,mgood,eblot,athomas
[TRAC_ADMIN:*]
admins = rw
[WIKI_MODIFY:TracDev/*]
cmlenz = rw
cboos = rw
[WIKI_VIEW:*]
* = rw
[TICKET_VIEW:*]
* = rw
[TICKET_MODIFY:*]
* = rw
[TICKET_ADMIN:*]
admins = rw
# Non-prefixed paths refer to BROWSER_VIEW
[/sandbox/*]
athomas = rw
And of course, administration of this file would be transparently
handled by trac-admin or WebAdmin through the API.
Alec
On Sat, Apr 15, 2006 at 08:10:28AM +1000, Alec Thomas wrote:
> Hi,
>
> I've been quite bored this weekend, and I've long wanted to see
> something like this in Trac.
>
> This patch [1] simply adds an extra facet to permissions: the resource
> the permission applies to. By default there is a wildcard (*) resource,
> meaning the permission applies to all resources. A resource can be
> prefixed with a hyphen to explicitly deny an action on that resource.
>
> The policy is this: from most to least explicit, try deny first, then
> allow. A '*' can be used at the end of a resource to perform wildcard
> matching.
>
> So permissions of "WIKI_VIEW:Sand*,-San*,*" will allow access to all pages
> including those starting with "Sand", but denying those starting with
> "San".
>
> Here's how to see if the user has WIKI_VIEW permissions for a particular
> page:
>
> if req.perm.has_permission('WIKI_VIEW', name): ...
>
> And to see if the user has some form of WIKI_VIEW permissions:
>
> if req.perm.has_some_permission('WIKI_VIEW'): ...
>
> (useful for the case where you wish to hide an item of the user does not
> have a permission).
>
> There's still a fair bit of work to do, obviously, but I'd like to get
> feedback on whether this approach looks appropriate.
>
> If you want to try the patch you'll need to alter your permission table,
> adding a new columnn 'resource'.
>
> Alec
>
> [1] http://swapoff.org/files/new-perms.diff
>
> Here's what "trac-admin <env> permission list" looks like:
>
> User Action Resources
>
> ------------------------------------------------------------------------------------------------------------
> anonymous BROWSER_VIEW *
>
> anonymous CHANGESET_VIEW *
>
> anonymous FILE_VIEW *
>
> anonymous LOG_VIEW *
>
> anonymous MILESTONE_VIEW *
>
> anonymous REPORT_VIEW *
>
> anonymous ROADMAP_VIEW *
>
> anonymous SEARCH_VIEW *
>
> anonymous TICKET_CREATE *
>
> anonymous TICKET_MODIFY *
>
> anonymous TICKET_VIEW *
>
> anonymous TIMELINE_VIEW *
>
> anonymous WIKI_MODIFY SandBox
>
> anonymous WIKI_VIEW
> HowToContribute,RecentChanges,SandBox,TitleIndex,Trac*,WikiFormatting,WikiStart
>
> --
> Evolution: Taking care of those too stupid to take care of themselves.
> _______________________________________________
> Trac-dev mailing list
> [email protected]
> http://lists.edgewall.com/mailman/listinfo/trac-dev
>
--
Evolution: Taking care of those too stupid to take care of themselves.
_______________________________________________
Trac-dev mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-dev
