Changes between Version 45 and Version 46 of S3/S3AAA

Timestamp:

01/18/11 01:22:32 (13 years ago)

Author:

Dominic König

Comment:

--

S3/S3AAA

@@ -102 +102 @@
 In tables which do not define either of these meta-fields, ownership rules are not applied ({{{uacl}}} only).
 
-=== !Controller/Table Restriction ===
+=== Restrictions ===
 
 ACLs can be defined for controllers, and for particular functions inside controllers.[[BR]]
 ACLs can additionally be defined for individual database tables.
 
-The controller ACLs are activated by setting the respective controller to {{{restricted=True}}} in {{{deployment_settings.modules}}} ({{{000_config.py}}}):
+==== System-wide Policy ====
+
+To configure the system-wide policy to use ACLs, set {{{security.policy}}} in deployment settings ({{{models/000_config.py}}}):
+
+{{{
+deployment_settings.security.policy = 3 # Apply Controller ACLs
+}}}
+
+or:
+
+{{{
+deployment_settings.security.policy = 4 # Apply both Controller and Table ACLs
+}}}
+
+==== Controller Restriction ====
+
+Furthermore, it must be specified for which controllers to ACLs are to be used. This can be done by setting the respective controller to {{{restricted=True}}} in {{{deployment_settings.modules}}} ({{{models/000_config.py}}}):
 
 {{{
@@ -114 +130 @@
             description = T("Disaster Victim Identification"),
 
-            restricted = True, # Apply controller ACLs
+            restricted = True, # Apply controller ACLs for the dvi module
 
             module_type = 10,
@@ -123 +139 @@
 }}}
 
-If {{{restricted}}} is {{{False}}} or not defined, then simple authorization is used for this controller.
+If {{{restricted}}} is {{{False}}} or undefined for a controller, then simple authorization is used for controller access.
 
 The Controller ACL can be defined for all functions in a controller, and additionally for particular functions inside a controller, where the function-specific ACLs override the general controller ACL. That means, you can define a general ACL for the {{{pr}}} controller, and a different one for the {{{pr/person}}} function.
@@ -129 +145 @@
 The Controller ACLs are applied to ''all'' resources when accessed through this controller/function. If the Controller ACL does not give any permission for the current user (ACL value==auth.permissions.NONE==0x00), then the request is rejected as "Unauthorized". Controllers do not have to implement this check - this is done at a central place (in {{{00_utils.py}}}).
 
+==== Table Restriction ====
+
 Once the user has passed that controller permission check (must have at least {{{read}}} permission), and tries to access to a particular table, then the controller checks for table-specific ACLs. This check is to be implemented by the particular controller using {{{s3_has_permission()}}} and {{{s3_accessible_query}}} (except controllers using S3CRUD only, which already contains it).
 
+If there is no ACL defined for this table at all (i.e. for none of the users), then the table is considered unrestricted and only the controller ACLs apply.
+
+If there exist ACLs for this table, but not for the current user, access is '''denied''' for the current user.
+
+If there are specific ACLs defined for this table and the current user, then the most ''restrictive'' of the controller and table ACLs apply (i.e. you cannot allow on the table level what you forbid at the controller level, and vice versa).
+
   '''Note:''' ''For consistency reasons, creating or deleting component records in a resource requires additional permission to update the main record, even though the main record is not changed by this operation, e.g. to add an address to a person record, you must also be permitted to update the person record.''
-
-If there are specific ACLs defined for the table, then the most ''restrictive'' of controller and table ACLs apply (i.e. you cannot allow on the table level what you forbid at the controller level, and vice versa). If there are no specific ACLs defined for this table, then the controller ACLs apply.
-
 == Implementation of Access Control ==