issue_comments

I'm going to implement the first version of this token mechanism using permissions that exist already. Right now that's:

https://docs.datasette.io/en/0.62/authentication.html#built-in-permissions

Here are the shortcuts I'll use for them:

• view-instance - vi
• view-database - vd
• view-database-download - vdd
• view-table - vt
• view-query - vq
• execute-sql - es

Might be neat for API tokens to be signed with an additional secret than can be rotated independently of DATASETTE_SECRET itself, in order to invalidate all tokens without needing to invalidate logged in users too.

But again, I don't want to implement something like that until I see an actual need for it.

... also, maybe there should be a UI (perhaps on that page) for resetting the Datasette secret? Useful for emergency invalidation of all tokens.

No, I'm not going to build that unless someone asks for it. Restarting the server with a fresh secret should be easy enough.

If you start Datasette without providing a DATASETTE_SECRET environment variable of --secret option it creates a random signing secret that only lasts for the lifetime of the server.

This means any signed API tokens you create will stop working if the server restarts.

I think the /-/create-token UI should know when this happens and show a warning message about it, to avoid confusion.

Here's what that example looks like signed: python from datasette.app import Datasette ds = Datasette() ds.sign('{"t":{"a":["ir","ur","dr"],"d":{"fixtures":["ir","ur","dr"]},"t":{"fixtures":{"searchable":["ir"]}}}}') .eJxTqo5RKolRsgJSiUAqOkYpsyhGSSdGqRRCpQCpWBANUZOWWVFSWpRajFNprQ7cPCS1QF5xamJRckZiUk4qQm9sLRAoAQCC8yph.O0Gaej6-VOLbbtPq7xU6T77jEO0 That's 129 characters.

Note that Datasette doesn't have its own mechanism for signing things for a specific duration yet: https://docs.datasette.io/en/stable/internals.html#sign-value-namespace-default

So I'll need to add a "e": 1666739744 field with the UTC timestamp at which the token should expire.

Token design concept: json { "t": { "a": ["ir", "ur", "dr"], "d": { "fixtures": ["ir", "ur", "dr"] }, "t": { "fixtures": { "searchable": ["ir"] } } } } That JSON would be minified and signed.

Minified version of the above looks like this (101 characters):

{"t":{"a":["ir","ur","dr"],"d":{"fixtures":["ir","ur","dr"]},"t":{"fixtures":{"searchable":["ir"]}}}}

The "t" key shows this is a token that as a default API key.

"a" means "all" - these are permissions that have been granted on all tables and databases.

"d" means "databases" - this is a way to set permissions for all tables in a specific database.

"t" means "tables" - this lets you set permissions at a finely grained table level.

Then the permissions themselves are two character codes which are shortened versions - so:

• ir = insert-row
• ur = update-row
• dr = delete-row

Maybe these tokens can be restricted to specific databases and tables when they are first created?

Since they're signed tokens, I could bundle a bunch of extra stuff in them - this token is allowed to do these permissions against these tables/rows for example.

General wisdom seems to be that 8KB is a sensible maximum length for this kind of token, which is easily long enough to fit in a bunch of database / table / permissions.