allura.lib.security

This module provides the security predicates used in decorating various models.

class allura.lib.security.RoleCache(cred, q)

An iterable collection of ProjectRoles that is cached after first use

__init__(cred, q)
Parameters:
class allura.lib.security.Credentials

Role graph logic & caching

clear()

clear cache

classmethod get()

get the global Credentials instance :rtype: Credentials

load_project_roles(*project_ids)

Load the credentials with all user roles for a set of projects

load_user_roles(user_id, *project_ids)

Load the credentials with all user roles for a set of projects

project_roles(project_id)
Returns:a RoleCache of ProjectRoles for project_id
user_roles(user_id, project_id=None)
Returns:a RoleCache of ProjectRoles for given user_id and optional project_id, *anonymous and *authenticated checked as appropriate
users_with_named_role(project_id, name)

returns in sorted order

class allura.lib.security.RoleCache(cred, q)

An iterable collection of ProjectRoles that is cached after first use

allura.lib.security.all_allowed(obj, user_or_role=None, project=None)

List all the permission names that a given user or named role is allowed for a given object. This list reflects the permissions for which has_access() would return True for the user (or a user in the given named role, e.g. Developer).

Example:

Given a tracker with the following ACL (pseudo-code):

[
    ACE.allow(ProjectRole.by_name('Developer'), 'create'),
    ACE.allow(ProjectRole.by_name('Member'), 'post'),
    ACE.allow(ProjectRole.by_name('*anonymous'), 'read'),
]

And user1 is in the Member group, then all_allowed(tracker, user1) will return:

set(['post', 'read'])

And all_allowed(tracker, ProjectRole.by_name('Developer')) will return:

set(['create', 'post', 'read'])
allura.lib.security.has_access(obj, permission, user=None, project=None)

Return whether the given user has the permission name on the given object.

  • First, all the roles for a user in the given project context are computed.
  • If the given object’s ACL contains a DENY for this permission on this user’s project role, return False and deny access. TODO: make ACL order matter instead of doing DENY first; see ticket [#6715]
  • Next, for each role, the given object’s ACL is examined linearly. If an ACE is found which matches the permission and user, and that ACE ALLOWs access, then the function returns True and access is permitted. If the ACE DENYs access, then that role is removed from further consideration.
  • If the obj is not a Neighborhood and the given user has the ‘admin’ permission on the current neighborhood, then the function returns True and access is allowed.
  • If the obj is not a Project and the given user has the ‘admin’ permission on the current project, then the function returns True and access is allowed.
  • If none of the ACEs on the object ALLOW access, and there are no more roles to be considered, then the function returns False and access is denied.
  • Processing continues using the remaining roles and the obj.parent_security_context(). If the parent_security_context is None, then the function returns False and access is denied.

The effect of this processing is that:

  1. If the user’s project_role is DENYed, access is denied (e.g. if the user has been blocked for a permission on a specific tool).
  2. Else, if any role for the user is ALLOWed access via a linear traversal of the ACLs, then access is allowed.
  3. Otherwise, DENY access to the resource.
allura.lib.security.require(predicate, message=None)

Example: require(has_access(c.app, 'read'))

Parameters:
  • predicate (callable) – truth function to call
  • message (str) – message to show upon failure
Raises:

HTTPForbidden or HTTPUnauthorized

allura.lib.security.require_authenticated()
Raises:HTTPUnauthorized if current user is anonymous