* Issue 2429 indicates the possiblity of an open redirect
The 404 processing ends up redirecting a request with multiple path
slashes to that site, i.e.
https://my-site//shedcode.co.uk will redirect to https://shedcode.co.uk
This commit uses a regular expression to remove the multiple leading
slashes before redirecting.
Simplified Action by moving takes_child/takes_parent logic to Resource
- Removed InstanceResource - global actions are now simply those with resource_class=None
- Resource.parent_class - Replaced parent_name: str with parent_class: type[Resource] | None for direct class references
- Simplified Action dataclass - No more redundant fields, everything is derived from the Resource class structure
- Validation - The __init_subclass__ method now checks parent_class.parent_class to enforce the 2-level hierarchy
Closes#2563
* Add keyset pagination to allowed_resources()
This replaces the unbounded list return with PaginatedResources,
which supports efficient keyset pagination for handling thousands
of resources.
Closes#2560
Changes:
- allowed_resources() now returns PaginatedResources instead of list
- Added limit (1-1000, default 100) and next (keyset token) parameters
- Added include_reasons parameter (replaces allowed_resources_with_reasons)
- Removed allowed_resources_with_reasons() method entirely
- PaginatedResources.all() async generator for automatic pagination
- Uses tilde-encoding for tokens (matching table pagination)
- Updated all callers to use .resources accessor
- Updated documentation with new API and examples
The PaginatedResources object has:
- resources: List of Resource objects for current page
- next: Token for next page (None if no more results)
- all(): Async generator that yields all resources across pages
Example usage:
page = await ds.allowed_resources("view-table", actor, limit=100)
for table in page.resources:
print(table.child)
# Iterate all pages automatically
async for table in page.all():
print(table.child)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
This adds a new endpoint at /-/actions that lists all registered actions
in the permission system. The endpoint supports both JSON and HTML output.
Changes:
- Added _actions() method to Datasette class to return action list
- Added route for /-/actions with JsonDataView
- Created actions.html template for nice HTML display
- Added template parameter to JsonDataView for custom templates
- Moved respond_json_or_html from BaseView to JsonDataView
- Added test for the new endpoint
The endpoint requires view-instance permission and provides details about
each action including name, abbreviation, description, resource class,
and parent/child requirements.
Closes#2547
Co-Authored-By: Claude <noreply@anthropic.com>
This fixes issues introduced by the ruff commit e57f391a which converted
Optional[x] to x | None:
- Fixed datasette/app.py line 1024: Dict[id | str, Dict] -> Dict[int | str, Dict]
(was using id built-in function instead of int type)
- Fixed datasette/app.py line 1074: Optional["Resource"] -> "Resource" | None
- Added 'from __future__ import annotations' for Python 3.10 compatibility
- Added TYPE_CHECKING blocks to avoid circular imports
- Removed dead code (unused variable assignments) from cli.py and views
- Removed unused imports flagged by ruff across multiple files
- Fixed test fixtures: moved app_client fixture imports to conftest.py
(fixed 71 test errors caused by fixtures not being registered)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Updated check_visibility() method signature to accept Resource objects
(DatabaseResource, TableResource, QueryResource) instead of plain strings
and tuples.
Changes:
- Updated check_visibility() signature to only accept Resource objects
- Added validation with helpful error message for incorrect types
- Updated all check_visibility() calls throughout the codebase:
- datasette/views/database.py: Use DatabaseResource and QueryResource
- datasette/views/special.py: Use DatabaseResource and TableResource
- datasette/views/row.py: Use TableResource
- datasette/views/table.py: Use TableResource
- datasette/app.py: Use TableResource in expand_foreign_keys
- Updated tests to use Resource objects
- Updated documentation in docs/internals.rst:
- Removed outdated permissions parameter
- Updated examples to use Resource objects
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Modified /-/allowed to show all reasons that grant access to a resource
- Changed from MAX(reason) to json_group_array() in SQL to collect all reasons
- Reasons now displayed as JSON arrays in both HTML and JSON responses
- Only show Reason column to users with permissions-debug permission
- Removed obsolete "Source Plugin" column from /-/rules interface
- Updated allowed_resources_with_reasons() to parse and return reason lists
- Fixed alert() on /-/allowed by replacing with disabled input state
Actor restrictions (_r) now integrate with the SQL permission layer via
the permission_resources_sql() hook instead of acting as a post-filter.
This fixes the issue where allowed_resources() didn't respect restrictions,
causing incorrect database/table listings at /.json and /database.json
endpoints for restricted actors.
Key changes:
- Add _restriction_permission_rules() function to generate SQL rules from _r
- Restrictions create global DENY + specific ALLOW rules using allowlist
- Restrictions act as gating filter BEFORE config/root/default permissions
- Remove post-filter check from allowed() method (now redundant)
- Skip default allow rules when actor has restrictions
- Add comprehensive tests for restriction filtering behavior
The cascading permission logic (child → parent → global) ensures that
allowlisted resources override the global deny, while non-allowlisted
resources are blocked.
Closes#2534
The self.permissions dictionary was declared in __init__ but never
populated - only self.actions gets populated during startup.
The get_permission() method was unused legacy code that tried to look
up permissions from the empty self.permissions dictionary.
Changes:
- Removed self.permissions = {} from Datasette.__init__
- Removed get_permission() method (unused)
- Renamed test_get_permission → test_get_action to match actual method being tested
All tests pass, confirming these were unused artifacts.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Fixed two bugs preventing the create token UI and tests from working:
1. **Template variable mismatch**: create_token.html was using undefined variables
- Changed `all_permissions` → `all_actions`
- Changed `database_permissions` → `database_actions`
- Changed `resource_permissions` → `child_actions`
These match what CreateTokenView.shared() actually provides to the template.
2. **Action abbreviation bug**: app.py:685 was checking the wrong dictionary
- Changed `self.permissions.get(action)` → `self.actions.get(action)`
The abbreviate_action() function needs to look up Action objects (which have
the `abbr` attribute), not Permission objects. This bug prevented action names
like "view-instance" from being abbreviated to "vi" in token restrictions.
Refs #2534🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Added a new helper method resource_for_action() that creates Resource
instances for a given action by looking up the action's resource_class.
This eliminates the ugly object.__new__() pattern throughout the codebase.
Refactored all places that were using object.__new__() to create Resource
instances:
- check_visibility()
- allowed_resources()
- allowed_resources_with_reasons()
Also refactored database view to use allowed_resources() with
include_is_private=True to get canned queries, rather than manually
checking each one.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Updated check_visibility() to use the action's resource_class to determine
the correct Resource type to instantiate, rather than hardcoding based on
the action name. This follows the pattern used elsewhere in the codebase
and properly supports QueryResource for view-query actions.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
This change integrates canned queries with Datasette's new SQL-based
permissions system by making the following changes:
1. **Default canned_queries plugin hook**: Added a new hookimpl in
default_permissions.py that returns canned queries from datasette
configuration. This extracts config-reading logic into a plugin hook,
allowing QueryResource to discover all queries.
2. **Async resources_sql()**: Converted Resource.resources_sql() from a
synchronous class method returning a string to an async method that
receives the datasette instance. This allows QueryResource to call
plugin hooks and query the database.
3. **QueryResource implementation**: Implemented QueryResource.resources_sql()
to gather all canned queries by:
- Querying catalog_databases for all databases
- Calling canned_queries hooks for each database with actor=None
- Building a UNION ALL SQL query of all (database, query_name) pairs
- Properly escaping single quotes in resource names
4. **Simplified get_canned_queries()**: Removed config-reading logic since
it's now handled by the default plugin hook.
5. **Added view-query to default allow**: Added "view-query" to the
default_allow_actions set so canned queries are accessible by default.
6. **Removed xfail markers**: Removed test xfail markers from:
- tests/test_canned_queries.py (entire module)
- tests/test_html.py (2 tests)
- tests/test_permissions.py (1 test)
- tests/test_plugins.py (1 test)
All canned query tests now pass with the new permission system.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Instead of logging permission checks as dicts with a 'resource' key,
use a typed dataclass with separate parent and child fields.
Changes:
- Created PermissionCheck dataclass in app.py
- Updated permission check logging to use dataclass
- Updated PermissionsDebugView to use dataclass attributes
- Updated PermissionCheckView to check parent/child instead of resource
- Updated permissions_debug.html template to display parent/child
- Updated test expectations to use dataclass attributes
This provides better type safety and cleaner separation between
parent and child resource identifiers.
Implements a new ensure_permission() method that is a convenience wrapper
around allowed() that raises Forbidden instead of returning False.
Changes:
- Added ensure_permission() method to datasette/app.py
- Updated all views to use ensure_permission() instead of the pattern:
if not await self.ds.allowed(...): raise Forbidden(...)
- Updated docs/internals.rst to document the new method
- Removed old ensure_permissions() documentation (that method was already removed)
The new method simplifies permission enforcement in views and makes the
code more concise and consistent.
The new SQL-based permission system always resolves to True or False,
so the concept of "used default" (tracking when no hook had an opinion)
is no longer relevant. Removes:
- used_default from permission check logging in app.py
- used_default from permission debug responses in special.py
- used_default display from permissions_debug.html template
- used_default from test expectations in test_permissions.py
This simplifies the permission system by eliminating the "no opinion" state.
Two fixes for database download permissions:
1. Added also_requires="view-database" to view-database-download action
- You should only be able to download a database if you can view it
2. Added view-database-download to default_allow_actions list
- This action should be allowed by default, like view-database
3. Implemented also_requires checking in allowed() method
- The allowed() method now checks action.also_requires before
checking the action itself
- This ensures execute-sql requires view-database, etc.
Fixes test_database_download_for_immutable and
test_database_download_disallowed_for_memory.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Changes:
- Fixed expand_foreign_keys() to use new check_visibility() signature
without the 'permissions' keyword argument
- Removed 'default' parameter from allowed() call in filters.py
- Marked view-query tests as xfail since view-query permission is not yet
migrated to the new SQL-based permission system
Test improvements: 41 failures → 37 failures
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
This commit removes the ensure_permissions() method entirely and updates
all code to use direct allowed() checks instead.
Key changes:
- Removed ensure_permissions() method from datasette/app.py
- Simplified check_visibility() to check single permissions directly
- Replaced all ensure_permissions() calls with direct allowed() checks
- Updated all check_visibility() calls to use only primary permission
- Added Forbidden import to index.py
Why this change:
- ensure_permissions() used OR logic (any permission passes) which
conflicted with explicit denies in the config
- For example, check_visibility() called ensure_permissions() with
["view-database", "view-instance"] and if view-instance passed,
it would show pages even with explicit database deny
- The new approach checks only the specific permission needed for
each resource, respecting explicit denies
Test improvements: 64 failures → 41 failures
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Updated restrictions_allow_action() to use datasette.actions instead of datasette.permissions
- Changed references from Permission to Action objects
- Updated takes_database checks to takes_parent
- Added get_action() method to Datasette class for looking up actions by name or abbreviation
- Integrated actor restriction checking into allowed() method
- Actor restrictions (_r in actor dict) are now properly enforced after SQL permission checks
This fixes tests in test_api_write.py where actors with restricted permissions
were incorrectly being granted access to actions outside their restrictions.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Removed register_permissions hook definition from hookspecs.py
- Removed register_permissions implementation from default_permissions.py
- Removed pm.hook.register_permissions() call from app.py invoke_startup()
- The register_actions hook now serves as the sole mechanism for registering actions
- Removed Permission import from default_permissions.py as it's no longer needed
This completes the migration from the old register_permissions hook to the new
register_actions hook. All permission definitions should now use Action objects
via register_actions, and permission checking should use permission_resources_sql
to provide SQL-based permission rules.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Made allowed() accept resource=None with InstanceResource() as default
- Made both functions keyword-argument only
- Added logging to _permission_checks for debug endpoints
- Fixed check_permission_for_resource to handle empty params correctly
- Created build_permission_rules_sql() helper function for debug views
Major improvements to the allowed_resources() API:
1. **parent filter**: Filter results to specific database in SQL, not Python
- Avoids loading thousands of tables into Python memory
- Filtering happens efficiently in SQLite
2. **include_is_private flag**: Detect private resources in single SQL query
- Compares actor permissions vs anonymous permissions in SQL
- LEFT JOIN between actor_allowed and anon_allowed CTEs
- Returns is_private column: 1 if anonymous blocked, 0 otherwise
- No individual check_visibility() calls needed
3. **Resource.private property**: Safe access with clear error messages
- Raises AttributeError if accessed without include_is_private=True
- Prevents accidental misuse of the property
4. **Database view optimization**: Use new API to eliminate redundant checks
- Single bulk query replaces N individual permission checks
- Private flag computed in SQL, not via check_visibility() calls
- Views filtered from allowed_dict instead of checking db.view_names()
All permission filtering now happens in SQLite where it belongs, with
minimal data transferred to Python.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Renamed internal allowed_resources_sql() to _build_permission_rules_sql()
to avoid conflict with public method
- Made public allowed_resources_sql() keyword-only to prevent argument order bugs
- Fixed PermissionRulesView to use _build_permission_rules_sql() which returns
full permission rules (with allow/deny) instead of filtered resources
- Fixed _build_permission_rules_sql() to pass actor dict to build_rules_union()
- Added actor_id extraction in AllowedResourcesView
- Added root_enabled=True to test fixture to grant permissions-debug to root user
All 51 tests in test_permission_endpoints.py now pass.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
This introduces a new hierarchical permission system that uses SQL queries
for efficient permission checking across resources. The system replaces the
older permission_allowed() pattern with a more flexible resource-based
approach.
Core changes:
- New Resource ABC and Action dataclass in datasette/permissions.py
* Resources represent hierarchical entities (instance, database, table)
* Each resource type implements resources_sql() to list all instances
* Actions define operations on resources with cascading rules
- New plugin hook: register_actions(datasette)
* Plugins register actions with their associated resource types
* Replaces register_permissions() and register_resource_types()
* See docs/plugin_hooks.rst for full documentation
- Three new Datasette methods for permission checks:
* allowed_resources(action, actor) - returns list[Resource]
* allowed_resources_with_reasons(action, actor) - for debugging
* allowed(action, resource, actor) - checks single resource
* All use SQL for filtering, never Python iteration
- New /-/tables endpoint (TablesView)
* Returns JSON list of tables user can view
* Supports ?q= parameter for regex filtering
* Format: {"matches": [{"name": "db/table", "url": "/db/table"}]}
* Respects all permission rules from configuration and plugins
- SQL-based permission evaluation (datasette/utils/actions_sql.py)
* Cascading rules: child-level → parent-level → global-level
* DENY beats ALLOW at same specificity
* Uses CTEs for efficient SQL-only filtering
* Combines permission_resources_sql() hook results
- Default actions in datasette/default_actions.py
* InstanceResource, DatabaseResource, TableResource, QueryResource
* Core actions: view-instance, view-database, view-table, etc.
- Fixed default_permissions.py to handle database-level allow blocks
* Now creates parent-level rules for view-table action
* Fixes: datasette ... -s databases.fixtures.allow.id root
Documentation:
- Comprehensive register_actions() hook documentation
- Detailed resources_sql() method explanation
- /-/tables endpoint documentation in docs/introspection.rst
- Deprecated register_permissions() with migration guide
Tests:
- tests/test_actions_sql.py: 7 tests for core permission API
- tests/test_tables_endpoint.py: 13 tests for /-/tables endpoint
- All 118 documentation tests pass
- Tests verify SQL does filtering (not Python)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
* allowed_resources_sql plugin hook and infrastructure
* New methods for checking permissions with the new system
* New /-/allowed and /-/check and /-/rules special endpoints
Still needs to be integrated more deeply into Datasette, especially for listing visible tables.
Refs: #2502
---------
Co-authored-by: Claude <noreply@anthropic.com>
