issue_comments

I'm finding myself repeating this pattern a lot: python for table in table_counts: allowed = await self.ds.permission_allowed( request.scope.get("actor"), "view-table", resource_type="table", resource_identifier=(database, table), default=True, ) if not allowed: continue private = not await self.ds.permission_allowed( None, "view-table", resource_type="table", resource_identifier=(database, table), ) I use a similar pattern for lists of databases and lists of queries, and I'll be doing the same thing for lists of SQL views too.

An abstraction around this would be useful.

Idea:

python visible, private = await check_visibility( self.ds, actor, "view-table", "table", (database, table) )

Should the padlock show up on tables that are private only because they inherited their privacy from their parent database or even the parent instance?

Interesting question. If an instance is private, I'm not sure it makes sense to show padlocks on absolutely everything.

Likewise, a list of tables shown on the database table with a padlock next to every single table (when the database itself is private) doesn't seem to add any useful information.

I think "Show 🔒 in header on private database page" will resolve this for me. I'll always show the padlock in the header of a database/table page even if that privacy is inherited - but I won't do that for padlocks shown in the list of tables or list of databases.

I really like the padlocks. I should include a screenshot in the documentation that illustrates them.

Maybe I should figure out a way to have the https://latest.datasette.io/ demo illustrate both a logged-in and a logged-out state.

New convention: the 🔒 icon is now shown next to resources that are private - that are visible to you now, but would not be visible to the anonymous user.

Per-table permissions is pretty interesting for large installations though - an organization might have hundreds of CSV files imported into Datasette and then allow users to specify which exact users within that organization are allowed to see which CSV.

Oh this is a bit awkward - should I be running per-table permission checks for every table that might be shown on the index page?

I should take these permissions into account when displaying a list of tables or a list of databases (like I do right now when displaying a list of queries).

Do row-level permissions even make sense? Might be a good idea to remove those until I have a good use-case for them.

Also need to expand the docs on https://datasette.readthedocs.io/en/latest/authentication.html to explain where you can put allow blocks to control access to the instance, database or table.

I'd like to be able to apply permissions for the ability to run a SQL query - but I'm not sure where the best place for that "allow" block to live would be.

The tests in test_permissions.py could check the .json variants and assert that permission checks were carried out too.

Next step: fix this - # TODO: fix this to use that permission check - if not actor_matches_allow( - request.scope.get("actor", None), metadata.get("allow") - ): - return Response("Permission denied", status=403)

I'm going to add a test_permissions.py module that checks for 403 errors against different patterns of the actors block at different levels in metadata.json.

Testing pattern: python def test_canned_query_with_custom_metadata(app_client): response = app_client.get("/fixtures/neighborhood_search?text=town") assert_permissions_checked( app_client.ds, [ "view-instance", ("view-database", "database", "fixtures"), ("view-query", "query", ("fixtures", "neighborhood_search")), ], )

I'll need a neat testing pattern for this.

If the allow block at the database level forbids access this needs to cascade down to the table, query and row levels as well.