simonw/datasette 1.0a20

on GitHub

This alpha introduces a major breaking change prior to the 1.0 release of Datasette concerning how Datasette's permission system works.

Permission system redesign

Previously the permission system worked using datasette.permission_allowed() checks which consulted all available plugins in turn to determine whether a given actor was allowed to perform a given action on a given resource.

This approach could become prohibitively expensive for large lists of items - for example to determine the list of tables that a user could view in a large Datasette instance each plugin implementation of that hook would be fired for every table.

The new design uses SQL queries against Datasette's internal catalog tables to derive the list of resources for which an actor has permission for a given action. This turns an N x M problem (N resources, M plugins) into a single SQL query.

Plugins can use the new permission_resources_sql(datasette, actor, action) hook to return SQL fragments which will be used as part of that query.

Plugins that use any of the following features will need to be updated to work with this and following alphas (and Datasette 1.0 stable itself):

• Checking permissions with datasette.permission_allowed() - this method has been replaced with datasette.allowed().
• Implementing the permission_allowed() plugin hook - this hook has been removed in favor of permission_resources_sql().
• Using register_permissions() to register permissions - this hook has been removed in favor of register_actions().

Consult the v1.0a20 upgrade guide for further details on how to upgrade affected plugins.

Plugins can now make use of two new internal methods to help resolve permission checks:

• datasette.allowed_resources() returns a PaginatedResources object with a .resources list of Resource instances that an actor is allowed to access for a given action (and a .next token for pagination).
• datasette.allowed_resources_sql() returns the SQL and parameters that can be executed against the internal catalog tables to determine which resources an actor is allowed to access for a given action. This can be combined with further SQL to perform advanced custom filtering.

Related changes:

• The way datasette --root works has changed. Running Datasette with this flag now causes the root actor to pass all permission checks. (#2521)
• Permission debugging improvements:
  • The /-/allowed endpoint shows resources the user is allowed to interact with for different actions.
  • /-/rules shows the raw allow/deny rules that apply to different permission checks.
  • /-/actions lists every available action.
  • /-/check can be used to try out different permission checks for the current actor.

Other changes

• The internal catalog_views table now tracks SQLite views alongside tables in the introspection database. (#2495)
• Hitting the / brings up a search interface for navigating to tables that the current user can view. A new /-/tables endpoint supports this functionality. (#2523)
• Datasette attempts to detect some configuration errors on startup.
• Datasette now supports Python 3.14 and no longer tests against Python 3.9.