Changes between Version 7 and Version 8 of TracDev/Proposals/EvenFinerGrainedPermissions

Timestamp:

Jun 28, 2015, 11:09:27 PM (9 years ago)

Author:

figaro

Comment:

Cosmetic changes

TracDev/Proposals/EvenFinerGrainedPermissions

@@ -1 @@
-= Even finer grained permissions...
+= Even finer grained permissions
 
-Starting with [milestone:0.11] and the completion of the TracDev/SecurityBranch, we enabled to have a [TracFineGrainedPermissions fine-grained permission model] at the level of individual Trac resources, making it possible to write all sorts of new permission policies.
+Starting with [milestone:0.11] and the completion of the TracDev/SecurityBranch, we enabled to have a [TracFineGrainedPermissions fine-grained permission model] at the level of individual Trac resources, making it possible to write new permission policies.
 
 == Problem
+
 However, there are a few shortcomings with this model:
  - incomplete information over the '''user''', notably identifying special relationships between the user and the resource being checked
@@ -24 +25 @@
 The advantage of such an approach is that we could reduce the available actions to a minimum, and at the same time give more freedom over the precision of the checks.
 
-Also, mixing the ''realm'' of resources into the name of actions is only a legacy of the pre-0.11 period, and besides backward compatibility there's no longer a need for that, as permissions are checked against specific resources (including `("realm", None)`-style resources representing a realm of resources in general).
+Also, mixing the ''realm'' of resources into the name of actions is only a legacy of the pre-0.11 period, and besides backward compatibility there's no longer a need for that, as permissions are checked against specific resources, including `("realm", None)`-style resources representing a realm of resources in general.
 
 == Solution
@@ -32 +33 @@
 For introducing more elaborate concepts about the '''user''', we could use virtual groups. In a similar way than  the ''authenticated'' group currently represents the sets of authenticated users, we could imagine group providers attributing special membership to an user, depending on which ''resource'' is being targeted. Therefore we could imagine an ''owner'' or ''author'' virtual groups (#7438).
 
-
 == Performance
-
 
 Even today, lots of permission checks and lots of policies could have a non-negligible performance impact, not to mention the complete inefficiency of some kind of permission related queries (#4245 - who are the users having that permission?).
 
-If we're going to add even more checks like suggested here, we will also need a somewhat more efficient infrastructure for performing those checks.
+If we're going to add even more checks like suggested here, we will also need a more efficient infrastructure for performing those checks.
 
 A few ideas:
  - policy registration: each `IPermissionPolicy` can register "patterns" of actions, resources and users it is interested in; only fire the permissions that match. Of course, there's a balance to find, and the pattern matching should not "cost" more than firing the rule. Also, determination of group membership should be cached when possible.
- - resource cache: some permission policies need to retrieve informationsabout the resources they're checking (e.g. [source:tags/trac-0.12/sample-plugins/permissions/vulnerability_tickets.py]). This could be avoided if the properties have already been retrieved before and we have a way to "reuse" them
-
+ - resource cache: some permission policies need to retrieve information about the resources they're checking, eg [source:tags/trac-0.12/sample-plugins/permissions/vulnerability_tickets.py]). This could be avoided if the properties have already been retrieved before and we have a way to "reuse" them.
 
 ----