Changes between Version 25 and Version 26 of BluePrintAuthorization

Timestamp:

06/19/10 15:41:52 (14 years ago)

Author:

Fran Boon

Comment:

--

BluePrintAuthorization

@@ -1 +1 @@
 = !BluePrint for Authorization =
 == User Stories ==
- * A Developer needs to be able to restrict access to a Module
+ * A Developer needs to be able to restrict access to a '''Module''':
   * ~~s3.modules in {{{01_modules.py}}}~~
   * Add Controller check as well as menu check.
@@ -37 +37 @@
 }}}
 
- * A Developer needs to be able to restrict access to a Function
+ * A Developer needs to be able to restrict access to a '''Function''':
   * ~~Decorator function : @auth.requires_membership("Administrator")~~
    * doesn't support OR (we could easily write our own function to do this, though)
 
- * A Developer needs to be able to restrict access to a resource
+ * A Developer needs to be able to restrict access to a '''Resource''':
   * REST controller can be blocked via a Decorator
-  * Full security policy can be invoked, but this is painful (based on protected by default & granted manually) & untested within S3 recently
-  * We could check for what other functions can access data? Sync. Hard to maintain though.
+   * we'd need to patch other functions, such as sync, which would be hard to maintain
+  * Full security policy (native web2py) can be invoked, but this is painful (based on protected by default & granted manually) & untested within S3 recently
   * Need a new method: open by default & restricted manually
-   * Needs to be a DAL-level method since not all accesses go via S3XRC.
    * Option1: Use an {{{auth_permission}}} table similar to Web2Py 'full' but just for tables & with {{{group_id}}} as {{{multiple=True}}}
    * Option2: Set within {{{000_config.py}}}, along with module permissions? (see above example)
     * Means less DAL calls
-   * Option3: Have an onaccept which auto-populates the reader_id/writer_id fields in records?
+   * Option3: Have an onvalidation which auto-populates the reader_id/writer_id fields in records?
     * Means that no additional auth check at table-level needed
+    * If done at validation time then it means that no extra DAL calls are done when creating resources (just extra field(s) within the 1 DAL call)
    * Once new solution in-place:
     * remove security_policy from {{{s3_setting}}} table & session ({{{00_utils.py}}})
     * modify {{{shn_action_buttons()}}} in {{{00_utils.py}}}
 
- * A Developer needs to be able to restrict access to a record
+ * A Developer needs to be able to restrict access to a '''Record''':
   * Add 2 reusable {{{multiple=True}}} fields to each table which needs this: {{{reader_id}}} & {{{writer_id}}} combined as {{{permissions_id}}}
    * Full backward compatibility since they default to None
-  * reader_id checked with a new API function (called from shn_read() & shn_list(), but also available for other functions)
+  * For List views modify {{{shn_accessible_query()}}} (called from {{{shn_list()}}} & {{{shn_search()}}})
    * combine with the {{{deleted==True}}} check?
     * makes it easier to then replace that check with an 'inactive' field which is a date instead of a boolean, so that records can be set to expire (as well as giving us easy access to know when a record was deleted)
-   * Option 1: Do the check alongside deleted as part of a big JOIN
+   * Preferred Option: Do the check alongside deleted as part of a big JOIN
 {{{
 def shn_accessible_query(table):
@@ -69 +69 @@
     - deleted records are filtered
     - records to which they don't have permissions are filtered
-    (Modified version of current function from models/01_crud.py)
     """
 
@@ -107 +106 @@
      * Combines the deleted into single API call
      * Single JOIN for optimal DB performance (Assumption needs testing)
-   * Option 2: Do the check in Python after the initial query has returned
+   * Alternate Option: Do the check in Python after the initial query has returned
     * Advantage: Might have better performance than complex DB string?
     * Disadvantage: More records pulled from DB than necessary
-  * writer_id checked within a modified {{{shn_has_permission()}}} (called from shn_update(), etc, but also available for other functions)
+
+  * For single records modify {{{shn_has_permission()}}} (called from {{{shn_create()}}}, {{{shn_delete()}}}, {{{shn_read()}}} & {{{shn_update()}}}, but also available for other functions)
 {{{
 def shn_has_permission(name, tablename, record_id = 0):
@@ -201 +201 @@
 }}}
    * Disadvantage: Slow
+
   * UI to manage the fields.
    * We expect relatively few groups per instance, so can use the checkboxes widget?
+    * can filter out some groups?
    * Have a single checkbox for 'Restrict access' which then opens out the 2 fields.