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. For table and view permissions, resource names use SQLite's case-insensitive identifier matching: Secret , secret and SECRET identify the same table. This applies to configuration rules, plugin rules and token restrictions. Only ASCII letters are case-insensitive; non-ASCII characters remain distinct. Conflicting rules for different spellings of the same name follow the usual deny-wins rule at the same scope. Names retain their original spelling in resource listings and permission explanations. Database names, stored query names and other resource types remain case-sensitive. 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. The built-in datasette.default_permissions.sqlite_statistics plugin denies view-table for sqlite_stat1 , sqlite_stat2 , sqlite_stat3 and sqlite_stat4 . These table-level denials also apply to root users and take precedence over configuration or plugin allow rules at the same scope. This controls table access and listings, without changing execute-sql or SQLite's internal use of statistics. A plugin can replace this policy by unregistering datasette.default_permissions.sqlite_statistics through datasette.pm and registering its own permission hook. Plugin registration is process-wide: replacing this policy affects every Datasette instance in that process. 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"]	[]