https://simonwillison.net/2020/Jul/1/datasette-045/

https://datasette.readthedocs.io/en/latest/changelog.html#v0-45

I've been testing the WIP using this in the console: javascript fetch('/data/add_name.json', { method: 'POST', body: 'name=XXXfetch', credentials: 'omit', headers: {'Content-Type': 'application/x-www-form-urlencoded'} }) .then(response => console.log(response)) Against a canned query configured like this: yaml databases: data: queries: add_name: sql: insert into names (name) values (:name) write: true I haven't got it to work yet. Latest error is this one: INFO: Uvicorn running on http://127.0.0.1:8001 (Press CTRL+C to quit) Traceback (most recent call last): File "/Users/simon/Dropbox/Development/datasette/datasette/app.py", line 975, in route_path await response.asgi_send(send) AttributeError: 'tuple' object has no attribute 'asgi_send' INFO: 127.0.0.1:49938 - "POST /data/add_name.json HTTP/1.1" 500 Internal Server Error It looks like I'm going to have to rethink how the BaseView code around tables, formats and hashes is structured in order to fix this. That's a big refactoring! I'm moving this to a new milestone for Datasette 0.46.

Don't forget to update the news in the README.

The latest release of https://github.com/simonw/datasette-auth-tokens (0.2) now supports SQL configuration of tokens.

Tokens get verified by plugins. So far there's only one: https://github.com/simonw/datasette-auth-tokens - which has you hard-coding plugins in a configuration file. I have a issue there to add support for database-backed tokens too: https://github.com/simonw/datasette-auth-tokens/issues/1

Well tests need to be updated.

I need to get tests working on Windows.

Codecov Report

Merging #883 into master will not change coverage. The diff coverage is n/a.

```diff @@ Coverage Diff @@

master #883 +/-

======================================= Coverage 83.42% 83.42%
======================================= Files 27 27
Lines 3632 3632
======================================= Hits 3030 3030
Misses 602 602
```

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 676bb64...251884f. Read the comment docs.

Turns out we should include hidden tables in the result dict, or we're breaking tests. I've committed a refactor https://github.com/simonw/datasette/pull/883/commits/4f06e1bf6fbe4b73be770b87f610bf7c0e6e3ea7

I am calling the API from another origin, so injecting CSRF token into templates wouldn't work.

EDIT:

I'll try the new version, it sounds promising

Bearer tokens sound interesting. Where do tokens come from? An auth provider of my choosing? How do they get verified?

Have you tried the method described here? https://datasette.readthedocs.io/en/latest/internals.html#csrf-protection - I'm happy to bulk out that section of the documentation if that doesn't help solve your problem.

I just closed #835 which should make CSRF protection easier to work with - it won't interfere with requests without cookies or requests with Authentication: Bearer token tokens. See also https://github.com/simonw/asgi-csrf/issues/11

You can try out pip install datasette==0.45a5 to get those features. Hopefully releasing a full 0.45 tomorrow.

Does this mean custom routes get to expose endpoints accepting POST requests? I've tried earlier to add some POST endpoints, but requests were being rejected by Datasette due to CSRF

This case may not be covered without extra work: https://github.com/simonw/datasette/blob/3ec5b1abf6afa2d22a3378092809a1a8c0249d26/datasette/views/database.py#L122-L123

This can be a plugin hook:

python @hookspec def forbidden(datasette, request, message, send): "Custom response for a 403 forbidden error" If the hook returns a Response object, it will be returned to the user. Plugins are likely to want to return a redirect response.

Maybe the hook can instead use the send argument to respond to the request and return True which means "I've responded to this"?

I'm going to leave send off for the moment - I can add that in the future if it turns out it would have been a good idea.

The response from this will never be a 302 - it will always be a 200 if the response worked or a 400 for bad parameters or a 500 for errors. The body returned will always be in JSON format.

I've just realized Datasette tries to count hidden tables too. There are 5 visible tables, 25 hidden tables, which I haven't realize earlier to consider their effect. I've turned off counting for hidden tables to see if it has any effect.

What's the point of counting FTS tables?

I'm going to add some tests for this.