Mercurial Repository: p/roundup/code: doc/security.txt comparison

comparison doc/security.txt @ 907:38a74d1351c5

documentation updates

author	Richard Jones <richard@users.sourceforge.net>
date	Mon, 29 Jul 2002 00:54:41 +0000
parents	502a5ae11cc5
children	299f4890427d

comparison

equal deleted inserted replaced

-:9a6a193fb62a
+:38a74d1351c5
 ===================
 Security Mechanisms
 ===================
-:Version: $Revision: 1.13 $
+:Version: $Revision: 1.14 $
 Current situation
 =================
 Current logical controls:
 than the From address. Support for strong identification through digital
 signatures should be added.
 5. The command-line tool has no logical controls.
 6. The anonymous control needs revising - there should only be one way to be
 an anonymous user, not two (currently there is user==None and
-user=='anonymous).
+user=='anonymous').
 Possible approaches
 ===================
 Individual assignment of Permission to User is unwieldy. The concept of a
 Role, which encompasses several Permissions and may be assigned to many Users,
 is quite well developed in many projects. Roundup will take this path, and
 allow the multiple assignment of Roles to Users, and multiple Permissions to
-Roles. These definitions will be stored in the hyperdb. They don't need to be
+Roles. These definitions are not persistent - they're defined when the
-pushed to the actual database though.
+application initialises.
 There will be two levels of Permission. The Class level permissions define
 logical permissions associated with all nodes of a particular class (or all
 classes). The Node level permissions define logical permissions associated
 with specific nodes by way of their user-linked properties.
-A security module defines::
+The security module defines::
-class InMemoryClass(hyperdb.Class):
+class Permission:
-''' Just be an in-memory class
+''' Defines a Permission with the attributes
-'''
+- name
-def __init__(self, db, classname, **properties):
+- description
-''' Set up an in-memory store for the nodes of this class
+- klass (optional)
-'''
-def create(self, **propvalues):
-''' Create a new node in the in-memory store
-'''
-def get(self, nodeid, propname, default=_marker, cache=1):
-''' Get the node from the in-memory store
-'''
-def set(self, *args):
-''' Set values on the node
-'''
-class PermissionClass(InMemoryClass):
-''' Include the default attributes:
-- name (String)
-- klass (String)
-- description (String)
 The klass may be unset, indicating that this permission is not
-locked to a particular class. That means there may be multiple
+locked to a particular hyperdb class. There may be multiple
 Permissions for the same name for different classes.
 '''
-class RoleClass(InMemoryClass):
+class Role:
-''' Include the default attributes:
+''' Defines a Role with the attributes
-- name (String, key)
+- name
-- description (String)
+- description
-- permissions (PermissionClass Multilink)
+- permissions
 '''
 class Security:
 def __init__(self, db):
-''' Initialise the permission and role classes, and add in the
+''' Initialise the permission and role stores, and add in the
 base roles (for admin user).
 '''
-def hasPermission(self, db, classname, permission, userid):
+def getPermission(self, permission, classname=None):
+''' Find the Permission matching the name and for the class, if the
+classname is specified.
+Raise ValueError if there is no exact match.
+'''
+def hasPermission(self, permission, userid, classname=None):
 ''' Look through all the Roles, and hence Permissions, and see if
 "permission" is there for the specified classname.
+'''
-'''
+def hasNodePermission(self, classname, nodeid, **propspec):
-def hasNodePermission(self, db, classname, nodeid, **propspec):
 ''' Check the named properties of the given node to see if the
 userid appears in them. If it does, then the user is granted
 this permission check.
 'propspec' consists of a set of properties and values that
 def addRole(self, **propspec):
 ''' Create a new Role with the properties defined in 'propspec'
 '''
-def addPermissionToRole(self, rolename, permissionid):
+def addPermissionToRole(self, rolename, permission):
 ''' Add the permission to the role's permission list.
-'rolename' is the name of the role to add 'permissionid'.
+'rolename' is the name of the role to add permission to.
 '''
 Modules such as ``cgi_client.py`` and ``mailgw.py`` define their own
 permissions like so (this example is ``cgi_client.py``)::
 db.security.addPermissionToRole('User', ai)
 In the dbinit ``init()``::
 # create the two default users
-r = db.getclass('role').lookup('Admin')
 user.create(username="admin", password=Password(adminpw),
 address=instance_config.ADMIN_EMAIL, roles='Admin')
-r = db.getclass('role').lookup('Anonymous')
 user.create(username="anonymous", roles='Anonymous')
 Then in the code that matters, calls to ``hasPermission`` and
 ``hasNodePermission`` are made to determine if the user has permission
 to perform some action::
 Anonymous Users
 ---------------
 The "anonymous" user must always exist, and defines the access permissions for
-anonymous users. The three ANONYMOUS_ configuration variables are subsumed by
+anonymous users. The three ``ANONYMOUS_`` configuration variables are
-this new functionality.
+subsumed by this new functionality.
 Action
 ======

Mercurial > p > roundup > code

comparison doc/security.txt @ 907:38a74d1351c5