Changes between Version 2 and Version 3 of BluePrintAuthorizationB

Timestamp:

06/20/10 14:24:22 (15 years ago)

Author:

Dominic König

Comment:

--

BluePrintAuthorizationB

@@ -3 +3 @@
 == General model ==
 
-Authorization is implemented for:
+Authorization is implemented for the following methods:
 
   - module access
@@ -13 +13 @@
 
   - if a method is not restricted, then it is accessible for everyone
-  - if a method is restricted, then access must be explicitly granted, otherwise access is declined (Allow=>Deny order)
+  - if a method is restricted, then access must be explicitly granted, otherwise its declined (Allow=>Deny order)
 
 Permissions are assigned to roles (not to individual users):
@@ -20 +20 @@
   - admin role is auth_group 1 (cannot be modified)
   - all methods on everything are allowed for members of the admin role
+
   - roles are assigned to users by auth_membership
-  - roles can be created after deployment
+    - this can happen either through admin UI or implicitly (no admin interaction)
+    - it must be possible to log this
+  - additional roles can be created after deployment
+    - this will usually happen implicitly, i.e. not through admin UI
+    - does not require a generic UI solution
   - roles of the actual user are re-read from the DB and stored in the session once per HTTP request
+    - caching of this re-reading needs a proper method for cache invalidation on update notification
+    - do not implement caching unless it really makes us performance problems
 
 There are two pseudo-roles for record access: