I think the next big step for this feature is for me to actually use it to build a few things.

It would be neat not to show write permissions against immutable databases too - and not hard from a performance perspective since it doesn't involve hundreds more permission checks.

That will need permissions to grow a flag for if they need a mutable database though, which is a bigger job.

Maybe I should have kept _memory listed for instances that are running with --crossdb enabled?

Yeah I think I should.

New interface now live at https://latest.datasette.io/-/create-token

It shouldn't be showing _memory though.

Tests can go here:

https://github.com/simonw/datasette/blob/d98a8effb10ce8fe04a03eae42baa8a9cb0ca3f7/tests/test_auth.py#L143-L160

I shipped a working interface. Could still do with some extra tests.

With tilde-encoding for database and table names the HTML looks like this:

html <input type="checkbox" name="table:weird:foo~3Abar:view-table">

Another option: I could set a time limit - say 200ms - on how long I'm willing to spend calculating permissions before displaying this form

First calculate view permissions for tables and databases (and maybe views and canned queries too).

Then see if I can check every permission that I'm going to show as a checkbox on this page. If I get that done within the time limit use that to show the options.

If I run out of time show all options and maybe include a note saying that some of them may not actually be available.

Also: don't show hidden tables.

Another thing to consider in the future: once Datasette can support thousands of tables (see #417) the list on this page will turn into multiple MBs of HTML, which may cause all kinds of problems - not to mention the overhead of all of those table visibility permission checks.

Hopefully by then I'll have a good fix for the permission listings problem: - #1152

And I can apply the same mechanism here.

I'm going to ignore the permissions issue for the moment - I'll allow people to select any permissions they like in any of the databases or tables that are visible to them (don't want to leak the existence of databases/tables to users who shouldn't be able to see them).

I think the value of getting this working outweights any potential confusion from not using finely grained permission checks to decide if the user should be able to apply a permission or not.

The tokens themselves won't be able to perform insert-row or similar if the user doesn't have the ability to do that, even if they selected that checkbox.

Here's the checkbox prototype: ```diff diff --git a/datasette/templates/create_token.html b/datasette/templates/create_token.html index a94881ed..1795ebaf 100644 --- a/datasette/templates/create_token.html +++ b/datasette/templates/create_token.html @@ -2,11 +2,20 @@

{% block title %}Create an API token{% endblock %}

+{% block extra_head %} +<style type="text/css"> +#restrict-permissions label { + display: inline; + width: 90%; +} +</style> +{% endblock %} + {% block content %}

Create an API token

-

This token will allow API access with the same abilities as your current user.

This token will allow API access with the same abilities as your current user, {{ request.actor.id }}

{% if errors %} {% for error in errors %} @@ -27,8 +36,39 @@ - + +

{% if token %}

Slightly tricky thing here is that it should only show permissions that the user themselves has - on databases and tables that they have permission to access.

I have a nasty feeling this may require looping through everything and running every permission check, which could get very expensive if there are plugins involved that do their own storage check to resolve a permission.

It's that classic permission system problem: how to efficiently iterate through everything the user has permission to do in one go?

Might be that I have to punt on that, and show the user a list of permissions to select that they might not actually have ability for.

Checkbox interface looks like this. It's not beautiful but it's good enough for the moment:

I think checkboxes will work well.

Here's the data I get back from them (as post_vars()):

{'all:debug-menu': 'on', 'all:insert-row': 'on', 'expire_duration': '', 'expire_type': '', 'table:fixtures:delete-row': 'on', 'table:fixtures:drop-table': 'on', 'table:fixtures:view-query': 'on'}

My <select multiple> prototype: ```diff diff --git a/datasette/templates/create_token.html b/datasette/templates/create_token.html index a94881ed..5bd641cc 100644 --- a/datasette/templates/create_token.html +++ b/datasette/templates/create_token.html @@ -6,7 +6,7 @@

Create an API token

-

This token will allow API access with the same abilities as your current user.

This token will allow API access with the same abilities as your current user, {{ request.actor.id }}

{% if errors %} {% for error in errors %} @@ -28,6 +28,36 @@ + +

{% if token %} diff --git a/datasette/views/special.py b/datasette/views/special.py index 30345d14..9d0fcd31 100644 --- a/datasette/views/special.py +++ b/datasette/views/special.py @@ -231,7 +231,17 @@ class CreateTokenView(BaseView): return await self.render( ["create_token.html"], request, - {"actor": request.actor}, + { + "actor": request.actor, + "all_permissions": self.ds.permissions.keys(), + "database_permissions": [key for key, value in self.ds.permissions.items() if value.takes_database], + "table_permissions": [key for key, value in self.ds.permissions.items() if value.takes_resource], + "databases": self.ds.databases.keys(), + "database_with_tables": [{ + "database": db.name, + "tables": await db.table_names(), + } for db in self.ds.databases.values()], + }, )

 async def post(self, request):

```

Got an option group thing working:

But... it strikes me that any time you're considering a <select multiple> like this a nested list of checkboxes would actually be better - easier for people to use.

I'm experimenting with a <select multiple> for this.

The usability for keyboards is still pretty awful, but it's a niche enough feature that maybe that's OK for the moment?

javascript var select = document.querySelector('select'); var selected = Array.from(temp0.options).filter(o => o.selected).map(o => o.value)

• [x] I should add a --database example to that help text.

https://latest.datasette.io/-/create-token currently looks like this:

As a reminder, the CLI options that this needs to provide an alternative to are:

https://github.com/simonw/datasette/blob/d4b98d3924dec625a99236e65b1b169ff957381f/docs/cli-reference.rst#L619-L638

I'm going to hide the options for reducing the scope of the token inside a details/summary element.

For the UI: I think I'm going to dump a whole bunch of form elements on the page (so you can set up to 3 of each category of limit without any JavaScript), then add JavaScript that hides all but one of the options and gives you a "add another" widget that adds multiple more.