issue_comments

I'm going to split the remaining work into separate issues:

• [x] #1856
• [ ] #1855

Documentation: https://docs.datasette.io/en/1.0-dev/authentication.html#api-tokens

Built a prototype of the actor_from_request() hook for this and now:

% curl http://127.0.0.1:8001/-/actor.json -H 'Authorization: Bearer dstok_eyJhIjoicm9vdCIsImUiOm51bGx9.6O1OxgNTFkAU6uw7xNcmXYX949A' {"actor": {"id": "root", "dstok": true}}

Implemented that dstok_ prefix and the thing where only the actor["id"] is copied to the "a" field.

Prefix: dstok_ - for Datasette signed token.

The tokens also need something that can be used to differentiate them from alternative token mechanisms that other plugins might provide.

Maybe a prefix before the signed value.

Prefixes are also useful for scanning to check they were not accidentally committed to source control.

Other options:

• --setting default_api_tokens off
• --setting signed_api_tokens off
• --setting allow_create_token off

These feel inconsistent because they don't use the allow_ prefix - but they're also a bit less ugly to look at.

I like that last one.

Rather than duplicating the entire actor into the "a" field, maybe just copy the actor ID?

Would need to restrict token creation to just actors with an ID set.

On that basis, I think the model described above where tokens mainly work to provide an "act on behalf of this actor" - but with optional additional constraints - is a good one.

This is what we do for Sandstorm essentially and I fully agree it's the right way to do API tokens in multiuser systems.

Constraints will definitely be important though. I know I want a token to submit error reports programmatically, but I wouldn't want that token to convey my right to delete tables and records, Little Bobby Tables is out there somewhere, and he's all grown up now.

Tests failed because I added a view without also adding documentation!

I forgot that the deploy still goes out for branches other than main even if the tests aren't passing: https://github.com/simonw/datasette/blob/c7dd76c26257ded5bcdfd0570e12412531b8b88f/.github/workflows/deploy-latest.yml#L34-L38

Another thought about tokens that can act on behalf of the user.

Imagine a user has permission to access a table. They create a token that can create that table... but then their permission is revoked. It would be bad if they could still use that token they created earlier to access that table!

On that basis, I think the model described above where tokens mainly work to provide an "act on behalf of this actor" - but with optional additional constraints - is a good one.

Next step: make these tokens actually do something.

If I'm going to change the naming conventions for settings I should do it before Datasette 1.0.

If I'm going to have a setting to disable this feature I need to decide what it will be called.

Closest existing setting is this one, since it's for a feature that is turned on by default:

datasette mydatabase.db --setting allow_download off

So maybe this?

datasette mydatabase.db --setting allow_signed_api_tokens off

I like allow_signed_api_tokens more than allow_api_tokens because if you install a plugin such as https://datasette.io/plugins/datasette-auth-tokens then API tokens will work even though you disabled this default signed token feature.

allow_signed_api_tokens does feel a bit clumsy/verbose though.

Demo is now live at https://latest-1-0-dev.datasette.io/-/create-token - visit https://latest-1-0-dev.datasette.io/login-as-root first to sign in.

If you click "Create token" for "Token never expires" multiple times you currently get exactly the same token each time, since it's just a signed token containing a copy of your actor dictionary.

I'm not sure if I like that. I could give each token a random ID (maybe using secrets.token_hex()) such that different tokens have different identities, which would be useful for logging and auditing and maybe even revocation at some point in the future.

Demo: