Changes between Version 25 and Version 26 of BluePrintAuthorization


Ignore:
Timestamp:
06/19/10 15:41:52 (11 years ago)
Author:
Fran Boon
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrintAuthorization

    v25 v26  
    11= !BluePrint for Authorization =
    22== User Stories ==
    3  * A Developer needs to be able to restrict access to a Module
     3 * A Developer needs to be able to restrict access to a '''Module''':
    44  * ~~s3.modules in {{{01_modules.py}}}~~
    55  * Add Controller check as well as menu check.
     
    3737}}}
    3838
    39  * A Developer needs to be able to restrict access to a Function
     39 * A Developer needs to be able to restrict access to a '''Function''':
    4040  * ~~Decorator function : @auth.requires_membership("Administrator")~~
    4141   * doesn't support OR (we could easily write our own function to do this, though)
    4242
    43  * A Developer needs to be able to restrict access to a resource
     43 * A Developer needs to be able to restrict access to a '''Resource''':
    4444  * REST controller can be blocked via a Decorator
    45   * Full security policy can be invoked, but this is painful (based on protected by default & granted manually) & untested within S3 recently
    46   * We could check for what other functions can access data? Sync. Hard to maintain though.
     45   * we'd need to patch other functions, such as sync, which would be hard to maintain
     46  * Full security policy (native web2py) can be invoked, but this is painful (based on protected by default & granted manually) & untested within S3 recently
    4747  * Need a new method: open by default & restricted manually
    48    * Needs to be a DAL-level method since not all accesses go via S3XRC.
    4948   * Option1: Use an {{{auth_permission}}} table similar to Web2Py 'full' but just for tables & with {{{group_id}}} as {{{multiple=True}}}
    5049   * Option2: Set within {{{000_config.py}}}, along with module permissions? (see above example)
    5150    * Means less DAL calls
    52    * Option3: Have an onaccept which auto-populates the reader_id/writer_id fields in records?
     51   * Option3: Have an onvalidation which auto-populates the reader_id/writer_id fields in records?
    5352    * Means that no additional auth check at table-level needed
     53    * 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)
    5454   * Once new solution in-place:
    5555    * remove security_policy from {{{s3_setting}}} table & session ({{{00_utils.py}}})
    5656    * modify {{{shn_action_buttons()}}} in {{{00_utils.py}}}
    5757
    58  * A Developer needs to be able to restrict access to a record
     58 * A Developer needs to be able to restrict access to a '''Record''':
    5959  * Add 2 reusable {{{multiple=True}}} fields to each table which needs this: {{{reader_id}}} & {{{writer_id}}} combined as {{{permissions_id}}}
    6060   * Full backward compatibility since they default to None
    61   * reader_id checked with a new API function (called from shn_read() & shn_list(), but also available for other functions)
     61  * For List views modify {{{shn_accessible_query()}}} (called from {{{shn_list()}}} & {{{shn_search()}}})
    6262   * combine with the {{{deleted==True}}} check?
    6363    * 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)
    64    * Option 1: Do the check alongside deleted as part of a big JOIN
     64   * Preferred Option: Do the check alongside deleted as part of a big JOIN
    6565{{{
    6666def shn_accessible_query(table):
     
    6969    - deleted records are filtered
    7070    - records to which they don't have permissions are filtered
    71     (Modified version of current function from models/01_crud.py)
    7271    """
    7372
     
    107106     * Combines the deleted into single API call
    108107     * Single JOIN for optimal DB performance (Assumption needs testing)
    109    * Option 2: Do the check in Python after the initial query has returned
     108   * Alternate Option: Do the check in Python after the initial query has returned
    110109    * Advantage: Might have better performance than complex DB string?
    111110    * Disadvantage: More records pulled from DB than necessary
    112   * writer_id checked within a modified {{{shn_has_permission()}}} (called from shn_update(), etc, but also available for other functions)
     111
     112  * For single records modify {{{shn_has_permission()}}} (called from {{{shn_create()}}}, {{{shn_delete()}}}, {{{shn_read()}}} & {{{shn_update()}}}, but also available for other functions)
    113113{{{
    114114def shn_has_permission(name, tablename, record_id = 0):
     
    201201}}}
    202202   * Disadvantage: Slow
     203
    203204  * UI to manage the fields.
    204205   * We expect relatively few groups per instance, so can use the checkboxes widget?
     206    * can filter out some groups?
    205207   * Have a single checkbox for 'Restrict access' which then opens out the 2 fields.
    206208