One option: if any rows were truncated, show a button you can click to run the query again with truncation disabled - maybe with ?_truncate=off in the URL or similar.

But... still want to truncate if the user runs a query that would return multiple MBs of HTML (assuming the other Datasette query limits don't stop that from happening).

Related: - #1875

Also weird: errors returned by that mechanism look like this: json { "ok": false, "errors": ["list of error messages"] } While errors returned by the rest of Datasette look like this: https://latest.datasette.io/fixtures/no_table.json

json { "ok": false, "error": "Table not found: no_table", "status": 404, "title": null } Related: - #1875

Looks like the code I've written for permission checking on TableCreateView and friends doesn't use the regular raise Forbidden or raise DatasetteError mechanisms - it does its own thing here:

https://github.com/simonw/datasette/blob/9ad76d279e2c3874ca5070626a25458ce129f126/datasette/views/database.py#L580-L584

Which uses this:

https://github.com/simonw/datasette/blob/9ad76d279e2c3874ca5070626a25458ce129f126/datasette/views/base.py#L547-L548

Having two different patterns to return errors is bad, I should fix that.

Easiest fix would be to look for accept: application/json and/or content-type: application/json headers.

Not bullet-proof, so people might occasionally make JSON requests and get back an HTML error - but the documentation can tell people that they need to send those headers if they want to reliably get back JSON error messages.

I'm happy with this as a solution.

Sniffing for a { is a little bit tricky though, as the post body is lazily loaded on request here:

https://github.com/simonw/datasette/blob/9ad76d279e2c3874ca5070626a25458ce129f126/datasette/utils/asgi.py#L127-L135

This raises a more complicated issue

At some point I'm likely to want to add an HTML interface for creating tables and inserting and updating rows.

The obvious URLs for that are the same as for the JSON API: /db/table/-/insert and suchlike.

Those endpoints are currently POST only - and can return JSON all the time.

If they start accepting form POSTs too they'll need to be able to accept form-encoded data and return HTML instead. That's OK - they can detect incoming JSON thanks to the content-type header an the fact that the request body starts with { - but the should_return_json fix described above could intefere with how errors are returned if I'm not careful.

I think it can still work though: I'll only set should_return_json = True if the endpoint gets a POST with a body starting {, or a content-type JSON header.

I'm going to prototype that up to see what it looks like.

I need a way for those JSON endpoints to communicate back to the handle_exception handler that they are returning JSON, so it knows to behave differently.

Since it gets the request object, one way could be to have view code set request.should_return_json = True so that the handler knows to do something different.

It's a bit of a cludge though!

Most .json errors DO return as JSON, thanks to this:

https://github.com/simonw/datasette/blob/c094dde3ff2bae030f261e6440d4fb082eb860a9/datasette/handle_exception.py#L19-L24

https://github.com/simonw/datasette/blob/c094dde3ff2bae030f261e6440d4fb082eb860a9/datasette/handle_exception.py#L57-L58

But that code triggers when the URL ends with .json - and none of the JSON write API endpoints (things like /db/-/create and /db/table/-/insert) follow that convention.

I'm going to test this using calls to ds.permission_allowed() with an actor with _r block.

I can add extra tests to https://github.com/simonw/datasette/blob/1a3dcf494376e32f7cff110c86a88e5b0a3f3924/tests/test_permissions.py#L605-L616

Also this code should work with non-abbreviations too.

I don't have much experience with Python; however, I wonder if this print statement needs flush=True?

https://github.com/simonw/datasette/blob/fdf7c27b5438f02153c3a7f8ad1b320e4b29e4f4/datasette/cli.py#L621

Hmm, it appears after I kill the process with Ctrl+c:

Non-memory named databases shouldn't show write actions, since those won't persist.

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.

Documentation for the new method: https://docs.datasette.io/en/latest/internals.html#create-token-actor-id-expires-after-none-restrict-all-none-restrict-database-none-restrict-resource-none

I like that the word restrict reflects the _r in the actor/token.

Maybe this:

```python datasette.create_token("root", expires_after=3600, restrict_all=("view-query", "view-table"))

token = datasette.create_token("root", expires_after=3600, restrict_database={ "fixtures": ("view-query",) })

token = datasette.create_token("root", expires_after=3600, restrict_resource={ "fixtures": { "facetable": ("insert-row", "update-row") } }) ```

The problem with all=(..) is it feels misleading - it's actually restricting the permissions made available to the token.

Likewise, databases= being a dict of restricted permissions isn't completely obvious.

And the nested tables= dictionary feels a bit odd too.

Some sketches: ```python

Token for root user

token = datasette.create_token("root")

Expiring in an hour

token = datasette.create_token("root", expires_after=3600) More complicated is when you want to restrict to specific permissions:python

Limited to view-query and view-table

token = datasette.create_token("root", expires_after=3600, all=("view-query", "view-table"))

I'm not sure about that all= name

Limits within a specific database:

token = datasette.create_token("root", expires_after=3600, databases={ "fixtures": ("view-query",) })

And specific tables:

token = datasette.create_token("root", expires_after=3600, tables={ "fixtures": { "facetable": ("insert-row", "update-row") } }) ```

It's going to look very similar to the CLI tool, at least in terms of capabilities: ``` Usage: datasette create-token [OPTIONS] ID

Create a signed API token for the specified actor ID

Example:

  datasette create-token root --secret mysecret

To allow only "view-database-download" for all databases:

  datasette create-token root --secret mysecret \
      --all view-database-download

To allow "create-table" against a specific database:

  datasette create-token root --secret mysecret \
      --database mydb create-table

To allow "insert-row" against a specific table:

  datasette create-token root --secret myscret \
      --resource mydb mytable insert-row

Restricted actions can be specified multiple times using multiple --all, --database, and --resource options.

Add --debug to see a decoded version of the token. ```

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.

FYI @simonw, I don't see that message.