issue_comments

Documentation here: https://docs.datasette.io/en/latest/sql_queries.html#json-api-for-writable-canned-queries

The JSON response will look like this: json { "ok": true, "message": "A message", "redirect": "/blah" } "ok" will be true if everything went right and false if there was an error.

The "message" and "redirect" will be whatever was configured using the on_success_message - the message shown on_success_message, on_success_redirect, on_error_message and on_error_redirect settings, see https://docs.datasette.io/en/stable/sql_queries.html#writable-canned-queries

I'm going to support several ways of indicating that you would like a JSON response instead of getting a HTTP redirect from your writable canned query submission:

• Use the Accept: application/json request header
• Include ?_json=1 in the request query string
• Include "_json": 1 in the form submission (or the JSON body submission)

I'm going to add support for POST content that is sent as a JSON document, in addition to the existing support for key=value encoded POST bodies.

Relevant code section: https://github.com/simonw/datasette/blob/1552ac931e4d2cf516caac3ceeab4fd24da1510a/datasette/views/database.py#L209-L232

Answer: no, it's not safe to skip CSRF if there's an Accept: application/json header because of a nasty old crossdomain.xml Flash vulnerability: https://blog.appsecco.com/exploiting-csrf-on-json-endpoints-with-flash-and-redirects-681d4ad6b31b?gi=a5ee3d7a8235

Is it safe to skip CSRF checks if the incoming request has Accept: application/json on it?

I'm not sure that matters since asgi-csrf already won't reject requests that either have no cookies or are using a Authorization: Bearer ... header.

Maybe POST to .json doesn't actually make sense. I could instead support POST /db/queryname with an optional mechanism for requesting that the response to that POST be in a JSON format.

Could be a Accept: application/json header with an option of including "_accept": "json" as a POST parameter instead.

What should happen when something does a POST to an extension that was registered by a plugin, e.g. POST /db/table.atom ?

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.

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.