A Role identifies who's making a call, and what they're allowed to do. What they're allowed to do is given by a list of Policys (more details here). Some Policys can be configured - have parameters given to them. These are stored in the Role.
A Role can also have parents. When parents are provided, they provide the starting point for the Role's Policys. This allows, for example, a Role to be created with restricted access to somebody else's resources - a bit like setuid.
Each User must have a default Role. The default Role is used for api access from web pages by that user. A Role named '' is treated as a default Role. It is recommended any non-default Role should have the same Users default Role as an ancenstor (a parent or a parent's parent, ...).
A Role can do everything the Policys allow it - if one Policy allows it, the Role can do it.
A Policy starts with the premission given by all the Role's parents, and then trims that back to just what is needed. When there are no parents, this is effectively 'do anything as the Role's User.
Policys can have parameters - these are set by the Role. These can be constants, or python expressions, with a few limits to avoid security leaks, or DOS attacks.
We recommended that other Roles owned by the same user have the Users default Role as a parent. When you do this, the default Role becomes a gate keeper for that Users access through the api. Changing the Policys attached to the default Role allow you to regulate what that User can do. For example, a newly registered User might only being allowed to delete their account, and only once they've verified their email address, say, is the rest of your api permitted.
Role's owner.Role. You must add at least one Policy, otherwise the role can do nothing.Role. Use '' for User's default Roles - and require a name for any other Roles.Role was created.Roles of this Role. Default Roles don't need parents, other ones do.Role sets for evaluating Policies.Role was last used (by an api call)deep_update_parameters(update)->Nonecheck_parameters(params)->None staticrole_allows_api(action, kwargs, resources, user_check, context, policies, ignore_resource_policies)->BoolCheck if the action is allowed by thie Role.
actionkwargsresources(path, resource, access) from the call where the path is the path to the resource in the arguments, resource is the resource itself,
and access is a ResourceAccess for how the method will use the resource.user_check = lambda user: TruecontextPolicyContext for this check. context.context is the context for evaluating substitutions - it defines the values available.policiespolicies(ctx:PolicyContext) returns an iterable of ResourceUsesPolicy(models.Model) giving the policies for this method.ignore_resource_policiesfor_context()Role overrides this to provide:
.api_id, .urn, .owning_user.created_rolesRole being checked(path, resource, access) of all resources used in the callThis enum specifies how a resource is being accessed by a method.
.Publicdescribe_user_brief, for example..Readdescribe_user, for example..Fullmodify_user for example.