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:
cred (Credentials) –
Credentials
q (iterable) – An iterable (e.g a query) of
ProjectRoles
- 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
ofProjectRoles
for project_id
- user_roles(user_id, project_id=None)¶
- Returns:
a
RoleCache
ofProjectRoles
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
- exception allura.lib.security.HIBPClientError¶
Represents an unexpected failure consuming the HIBP API
- exception allura.lib.security.HIBPCompromisedCredentials(count, partial_hash)¶
Raised when a sha1 hash of a password is found to be compromised according to HIBP
- 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: str, user: M.User | None = None, project: M.Project | None = None, roles=None) bool ¶
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:
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).
Else, if any role for the user is ALLOWed access via a linear traversal of the ACLs, then access is allowed.
Otherwise, DENY access to the resource.
- allura.lib.security.require(predicate, message=None)¶
Example:
require(has_access(c.app, 'read'))
- allura.lib.security.require_authenticated()¶
- Raises:
HTTPUnauthorized if current user is anonymous