Changes between Version 2 and Version 3 of BluePrintAuthorizationB


Ignore:
Timestamp:
06/20/10 14:24:22 (11 years ago)
Author:
Dominic König
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrintAuthorizationB

    v2 v3  
    33== General model ==
    44
    5 Authorization is implemented for:
     5Authorization is implemented for the following methods:
    66
    77  - module access
     
    1313
    1414  - if a method is not restricted, then it is accessible for everyone
    15   - if a method is restricted, then access must be explicitly granted, otherwise access is declined (Allow=>Deny order)
     15  - if a method is restricted, then access must be explicitly granted, otherwise its declined (Allow=>Deny order)
    1616
    1717Permissions are assigned to roles (not to individual users):
     
    2020  - admin role is auth_group 1 (cannot be modified)
    2121  - all methods on everything are allowed for members of the admin role
     22
    2223  - roles are assigned to users by auth_membership
    23   - roles can be created after deployment
     24    - this can happen either through admin UI or implicitly (no admin interaction)
     25    - it must be possible to log this
     26  - additional roles can be created after deployment
     27    - this will usually happen implicitly, i.e. not through admin UI
     28    - does not require a generic UI solution
    2429  - roles of the actual user are re-read from the DB and stored in the session once per HTTP request
     30    - caching of this re-reading needs a proper method for cache invalidation on update notification
     31    - do not implement caching unless it really makes us performance problems
    2532
    2633There are two pseudo-roles for record access: