issue_comments

https://github.com/simonw/datasette/blob/29c5ff493ad7918b8fc44ea7920b41530e56dd5d/tests/test_permissions.py#L327-L348

datasette-auth-tokens can be the name. I can get a simple initial version of it running pretty quickly.

Alternative idea: a plugin that handles Bearer token authentication. Uses metadata.json with secret plugin values to map an incoming token to an actor dictionary, which can then be mapped to permissions.

I got this working: https://github.com/simonw/datasette-auth-github/pull/64

Just one problem: it uses the existing ds_actor cookie, which means it doesn't actually exercise the actor_from_request plugin!

It does use register_routes though.

I'm OK with not implementing this - I've got used to the existing mechanism, and it doesn't frustrate me enough to work on this more.

I think the new .check_permissions() should be a documented utility that is available to plugins. Maybe a method on datasette?

So for the following: await self.check_permissions(request, [ ("view-table", (database, table)), ("view-database", database), "view-instance", ]) The logic is: if the first test returns True, you get access. If it returns False you are denied. If it says None then move on to the next check in the list and repeat.

I'll add a new test in test_permissions.py which locks down an instance and then loops through paths as the anonymous user making sure they aren't accessible.

I'm tempted to add a view-instance check before routing any URLs, but that wouldn't be compatible with the idea in #832 that having view-table should be enough to view a table even if you don't pass view-instance.

A live demo running the datasette-auth-github plugin will help demonstrate this.

I've implemented this in a plugin instead: https://github.com/simonw/datasette-permissions-sql

How would I document this? Probably in another section on https://datasette.readthedocs.io/en/latest/authentication.html#permissions

But I'd also need to add documentation to the individual views stating what permissions are checked and in what order. I could do that on this page: https://datasette.readthedocs.io/en/latest/pages.html

datasette package fixtures.db --secret woot --branch master Sending build context to Docker daemon 260.6kB Step 1/9 : FROM python:3.8 3.8: Pulling from library/python e9afc4f90ab0: Downloading [=======> ] 7.195MB/50.39MB 989e6b19a265: Downloading [============================> ] 4.475MB/7.812MB af14b6c2f878: Downloading [===========================> ] 5.422MB/9.996MB 5573c4b30949: Waiting 11a88e764313: Waiting ee776f0e36af: Waiting 513c90a1afc3: Waiting df9b9e95bdb9: Waiting 86c9edb54464: Waiting ... datasette package fixtures.db --secret woot --branch master docker run -p 8001:8001 a155798bd842 This works too.

datasette publish cloudrun fixtures.db --service datasette-publish-secret --branch=master

https://datasette-publish-secret-j7hipcg4aq-uw.a.run.app/-/messages

datasette publish heroku fixtures.db -n datasette-publish-secret --branch=master

https://datasette-publish-secret.herokuapp.com/-/messages - Heroku works.

The way to manually test this is to publish a database to each provider and then check that the /-/messages debug tool works.

May the fix here is to implement a .check_permissions() method which passes when the first permission passes? python await self.check_permissions(request, [ ("view-table", (database, table)), ("view-database", database), "view-instance", ])

https://github.com/simonw/datasette-permissions-sql is now released as a 0.1a here: https://pypi.org/project/datasette-permissions-sql/

Relevant code:

https://github.com/simonw/datasette/blob/ce4958018ede00fbdadf0c37a99889b6901bfb9b/datasette/views/table.py#L267-L272