sections: authentication:authentication-permissions-explained

This data as json

id	page	ref	title	content	breadcrumbs	references
authentication:authentication-permissions-explained	authentication	authentication-permissions-explained	How permissions are resolved	Permission rules describe an effect ( allow or deny ) at one of three levels: resource A specific child resource, such as the analytics/sales table. parent A parent resource, such as the analytics database. A parent rule also applies to its child resources. global Every resource for that action. Datasette resolves matching rules from most specific to least specific: Resource rules take precedence over parent and global rules. Parent rules take precedence over global rules. If both allow and deny rules match at the same level, deny takes precedence. If no rule matches, access is denied. This means a resource-level allow can provide an exception to a parent-level deny. It also means that two plugins which disagree at the same level resolve to deny. Permission rule examples Matching rules Result Explanation Global allow Allow The global rule is the most specific matching rule. Global allow, parent deny Deny The parent rule is more specific. Parent deny, resource allow Allow The resource rule is more specific. Resource allow and resource deny Deny Deny takes precedence at the same level. No matching rules Deny Permissions default to deny when no rule applies. The built-in public defaults are global allow rules for actions such as view-instance , view-database and view-table . They follow the same precedence rules as configuration and plugin rules. The --default-deny option prevents Datasette from contributing those default allow rules. Datasette performs checks using await .allowed(*, action, resource, actor=None) , which accepts keyword arguments for action , resource and an optional actor . resource should be an instance of the appropriate Resource subclass from datasette.resources —for example InstanceResource() , DatabaseResource(database="... )`` or TableResource(database="...", table="...") . This defaults to InstanceResource() if not specified. When a check runs Datasette gathers allow/deny rules from multiple sources and compiles them into a SQL query. The resulting query describes all of the resources an actor may access for that action, together with the reasons those resources were allowed or denied. The combined sources are: allow blocks configured in datasette.yaml . Actor restrictions encoded into the actor dictionary or API token. The "root" user rule when --root (or Datasette.root_enabled ) is active. This is a global allow rule, so a more specific configuration deny can override it. Any additional SQL provided by plugins implementing permission_resources_sql(datasette, actor, action) . Actor restrictions are applied after the allow/deny rules. They act as an additional allowlist: a restriction can remove access but cannot grant access that the actor did not already have. See Restricting the actions that a token can perform . Some actions have dependencies on other actions. These are evaluated as an AND condition. For example, execute-sql also requires view-database : both decisions must be allowed for the final result to be allowed.	["Authentication and permissions", "Permissions"]	[]