Changes between Version 61 and Version 62 of BluePrintAuthorization

Timestamp:

06/19/10 22:47:46 (14 years ago)

Author:

Fran Boon

Comment:

--

BluePrintAuthorization

@@ -1 +1 @@
 = !BluePrint for Authorization =
 == Roles ==
-Roles are stored in the {{auth_group}}.
-
-These have no links to the groups in {{{pr_group}}}.
-
-We are currently adopting a simplistic 3-tier approach of Person -> Role -> Permissions.
-
-We consider that the 4-tier approach of Person -> Group -> Role -> Permissions is unnecessarily complex for users, despite giving strong flexibility & the potential for advanced admins to move persons into roles in bulk & including future members of the group.
-
-Roles for the currently logged-in user are cached in the session for easy access throughout Model, Controllers & Views.
+ * Roles are stored in the {{auth_group}}.
+ * These have no links to the groups in {{{pr_group}}}.
+ * We are currently adopting a simplistic 3-tier approach of Person -> Role -> Permissions.
+ * We consider that the 4-tier approach of Person -> Group -> Role -> Permissions is unnecessarily complex for users, despite giving strong flexibility & the potential for advanced admins to move persons into roles in bulk & including future members of the group.
+ * Roles for the currently logged-in user are cached in the session for easy access throughout Model, Controllers & Views.
+  * Replace {{{auth.has_membership(group)}}} in default modules menu in {{{01_modules.py}}}
 In {{{models/00_utils.py}}}:
 {{{
@@ -26 +23 @@
     session.s3.roles = roles
 }}}
+
+=== Caching ===
+Cache should be invalidated as part of the onaccept for auth_group.update()
+ * This can be done by storing a key in the session & changing the key (Dominic to expand...)
+
 == Restrictions ==
 === Module restriction ===
@@ -31 +33 @@
  * Add Controller check as well as menu check.
   * {{{appadmin.py}}} & {{{dvi.py}}} have these already
+   * need modifying to use {{{session.s3.roles}}}
  * Configure permissions in {{{000_config.py}}} instead of {{{01_modules.py}}}
   * Change {{{deployment_settings.modules}}} from a list of strings to a Storage()
@@ -67 +70 @@
  * ~~Decorator function : @auth.requires_membership("Administrator")~~
   * doesn't support OR, doesn't support NOT
+  * not efficient now we have {{{session.s3.roles}}}
  * We need to write a function which handles OR & NOT: {{{shn_role_check(1, 2, not=(3))}}}
  * Developer can put in additional manual restrictions or alternate routes, as-required
@@ -107 +111 @@
         deleted = 1
 
-    try:
-        user_id = auth.user.id
-        _memberships = db.auth_membership
-        memberships = db(_memberships.user_id == user_id).select(_memberships.group_id, cache=(cache.ram, 60))
-    except:
-        memberships = None
-    
-    roles = []
-    for membership in memberships:
-        roles.append(membership.group_id)
+    roles = session.s3.roles
 
     if 1 in roles:
@@ -151 +146 @@
     """
 
-    try:
-        user_id = auth.user.id
-        _memberships = db.auth_membership
-        memberships = db(_memberships.user_id == user_id).select(_memberships.group_id, cache=(cache.ram, 60))
-    except:
-        memberships = None
-    
-    roles = []
-    for membership in memberships:
-        roles.append(membership.group_id)
+    roles = session.s3.roles
 
     table = db[tablename]
@@ -262 +248 @@
  * In model (for access by all controllers, such as sync):
 {{{
-try:
-    user_id = auth.user.id
-    _memberships = db.auth_membership
-    memberships = db(_memberships.user_id == user_id).select(_memberships.group_id, cache=(cache.ram, 60))
-except:
-    memberships = None
-
-roles = []
-for membership in memberships:
-    roles.append(membership.group_id)
-
 if 1 not in roles and deployment_settings.auth.roles["MyRole"] not in roles:
-    table.field.readable = False
-}}}
-  * NB If doing this then the roles checks inside {{{shn_has_permission()}}} & {{{shn_accessible_fields()}}} should be modified to read this global value instead of more DAL queries (even cached)!
+    table.field1.readable = False
+    table.field2.writable = False
+}}}
 
 === Location restriction ===
@@ -307 +282 @@
     * means extra logic every CRUD check when most resources don't need this
    
-=== Caching ===
-Permissions are cached to reduce overheads.
- * Cache should be invalidated as part of the onaccept for auth_group.update()
-  * This can be done by storing a key in the session & changing the key (Dominic to expand...)
-
 === Visibility of Options ===
 Ideally options which a user doesn't have permission for should be hidden from them.
@@ -352 +322 @@
  * '''FRP''': if a user has a role which would normally be granted permission to a resource has another role, then deny them access instead.
   * {{{shn_role_check}}} covers this: [wiki:BluePrintAuthorization#Functionrestriction]
-  * Option: Introduce full-blown model of Persons -> Groups (pr_group) -> Roles (auth_group) -> Permissions
-   * Downside: Extra layer of confusion for both Admins & Developers
-   * Upside: Very flexible for Admins to manage which users (in bulk & future members) get what access to resources (subject to sufficient roles being made available by the developer)
+
+ * '''FRP''':
+  * An 'IP User' is permitted to submit requests on behalf of his organisation.
+   1. Hide 'Create Request' menu item unless this role present
+   2. Restrict the 'create' right on the Requests table to members of this role
+   3. In View request_create provide jQuery which hides the {{{or_organisation field}}} for people with this role.
+   4. Match this server-side by providing a create_onvalidation hook which says that if someone in this role then set the Organisation to theirs.
+  * An 'IP Admin' is an 'IP User' who can, in addition, add new 'IP Users' to their organisation.
+   1. just has the IP_Admin role added to menu unhiding
+   2. just has the IP_Admin role added to restriction
+   3. just has the IP_Admin role added to jQuery hide
+   4. just has the IP_Admin role added to create_onvalidation
+   5. Hide 'Add IP User' menu item unless this role present
+    * this takes you to a specialised auth_membership form with the IP_User role preselected (can be done in jQuery hiding the selected real dropdown & putting text up in visible part instead)
+   6. Restrict the 'create' right on the {{{auth_membership}}} table to members of this role
+   7. Provide onvalidation on auth_membership to set the group_id to 'IP_User' if this role is set
+  * A 'FAC User' is an 'IP Admin' for all organisations, but without 'IP User' permissions except for their own organisation (=WFP).
+   1. just has the FAC_User role added to menu unhiding
+   2. just has the FAC_User role added to restriction
+   3. just has the FAC_User role added to jQuery hide
+   4. just has the FAC_User role added to create_onvalidation
+   5. takes to a normal form without the jQuery hiding (can be identical form just the jQuery doesn't activate for this role)
+   6. just has the FAC_User role added to restriction
+   7. just has the FAC_User role added to onvalidation
+  * A 'FAC Admin' is a 'FAC User' with additional 'IP User' permissions for all organisations.
+   1. just has the FAC_Admin role added to menu unhiding
+   2. just has the FAC_Admin role added to restriction
+   3. has nothing special (jQuery doesn't activate for this role)
+   4. has nothing special (no special onvalidation)
+   5. takes to a normal form without the jQuery hiding (can be identical form just the jQuery doesn't activate for this role)
+   6. just has the FAC_Admin role added to restriction
+   7. just has the FAC_Admin role added to onvalidation
+
 ----
 BluePrintAuthenticationAccess