The issues that should be referenced from this release are:

395, #519, #576, #699, #706, #774, #777, #781, #784, #788, #790, #797, #798, #800, #802, #804, #819, #822

Preview of the release notes is now available here: https://datasette.readthedocs.io/en/latest/changelog.html#v0-44

Documentation: https://datasette.readthedocs.io/en/latest/internals.html#setting-cookies-with-response-set-cookie

https://datasette.readthedocs.io/en/latest/authentication.html#the-ds-actor-cookie

AWS IAM uses action and resource terminology: https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_access-management.html - I think that's where I got that language:

json { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "dynamodb:*", "Resource": "arn:aws:dynamodb:us-east-2:123456789012:table/Books" } } I'm going to stick with "action" in its current meaning.

operation, procedure, process as alternative words for those menu items?

Last-minute thought:

Should I worry about calling permissions "actions", when I have an idea for a future plugin hook that allows plugins to add something I was going to call "actions" to database, table and row pages?

Those actions would take the form of menu item commands that Do Something to the selected object. If I use "actions" to mean permission names, will I be able to find a good alternative name for these dynamic menu items?

Now fully documented here: https://datasette.readthedocs.io/en/latest/contributing.html#setting-up-a-development-environment

$ python tests/fixtures.py fixtures.db fixtures-metadata.json fixtures-plugins
Test tables written to fixtures.db
- metadata written to fixtures-metadata.json
Wrote plugin: fixtures-plugins/register_output_renderer.py
Wrote plugin: fixtures-plugins/view_name.py
Wrote plugin: fixtures-plugins/my_plugin.py
Wrote plugin: fixtures-plugins/messages_output_renderer.py
Wrote plugin: fixtures-plugins/my_plugin_2.py

Switched to 0.44 milestone because I don't like shipping releases with known bugs.

https://datasette.readthedocs.io/en/latest/internals.html#csrf-protection

Alternative design: leave actor alone. Instead specify that allow blocks can look like this:

json { "allow": { "unauthenticated": true } }

I like this: the above block is very self-documenting.

The "id": "*" mechanism means there is already precedent for allow keys with special meaning.

I'm going with this design.

https://datasette.readthedocs.io/en/latest/authentication.html#defining-permissions-with-allow-blocks

Documented at the bottom of this section: https://github.com/simonw/datasette/blob/7633b9ab249b2dce5ee0b4fcf9542c13a1703ef0/docs/authentication.rst#defining-permissions-with-allow-blocks

When I implement this I should also document default allow vs default deny as a concept, and specify that default next to every documented permission.

Also: https://github.com/simonw/datasette/blob/dfff34e1987976e72f58ee7b274952840b1f4b71/datasette/views/special.py#L63-L76

Also a good reminder that I need a set_cookie() function (#795) so I don't have to mess around with SimpleCookie directly.

I should probably add a utility function for setting that cookie - right now the only code that does that is here:

https://github.com/simonw/datasette/blob/dfff34e1987976e72f58ee7b274952840b1f4b71/datasette/views/special.py#L63-L76

I'm going to figure this out by working with https://github.com/simonw/datasette-auth-github/issues/62

Docs now say:

The actor dictionary can be any shape - the design of that data structure is left up to the plugins. A useful convention is to include an "id" string, as demonstrated by the "root" actor below.

I'm torn between anonymous and anon - because the latter is less typing, and I envisage people writing a lot of code like this:

python if actor.get("anonymous"): # ...

I'm going with anonymous because it's that tiny bit clearer than anon.

Idea: the anonymous actor could be passed to actor_matches_allow() as:

json {"anonymous": true}

Then allow blocks like this could be used to allow them:

json { "plugins": { "datasette-upload-csvs": { "allow": { "anonymous": true } } } }

I don't like the "id" requirement.

I can think of plenty of situations where a unique ID might not be available:

• auth against an external token - an email address or a phone number for example
• auth using encrypted tokens - where decrypting the token tells you exactly what permissions that token should have, like in https://blog.thea.codes/building-a-stateless-api-proxy/

Changelog for this is going to be huge - 96 commits since 0.43 already! https://github.com/simonw/datasette/compare/0.43...master

I'm dropping this from the 0.44 milestone.

I should assert that "id" exists and is a string in the code that calls the actor_from_request hook.

I can't get Datasette working on Glitch installed from a URL - I'm going to try this on Glitch once I've shipped the 0.44 release in #806.

Create data.db with: echo '{"emoji": "🐯", "score": 0}' | sqlite-utils insert data.db emojis --pk=emoji - echo '{"emoji": "🐺", "score": 0}' | sqlite-utils insert data.db emojis --pk=emoji - Then run Datasette with this metadata.yaml: yaml title: Datasette Poll databases: data: queries: vote: sql: |- update emojis set score = score + 1 where emoji = :emoji write: true

I want a unit test that exercises this for both writable and regular canned queries.

Problem with that is it's more of a actor_from_request opportunity than permission_allowed. You could use actor_from_request to authenticate API clients from their Authorization: header, then use the regular "allow" blocks in metadata.json to actually assign their permissions.

The most interesting permissions plugin would be one that implements permissions against some kind of database schema, hence allowing admins to edit permissions through writable canned queries.

datasette-auth-bearer perhaps?

I want to build a plugin that does Authorization: Bearer xxx API key authentication.

I'm leaning towards request.url_vars.

Currently querystring parameters are accessed through request.args and POST variables through request.post_vars(). Would be good to have a name that was somewhat consistent with those.

Documentation: https://datasette.readthedocs.io/en/latest/plugins.html#register-routes

In the case of registering API tokens it would be useful if the plugin could call a writable canned query which knows how to insert a randomly generated value. This could be achieved using a custom SQL function.

WIP documentation: https://github.com/simonw/datasette/blob/770dedb21adfc706592e6b5cdf5e751a8720fdf9/docs/plugins.rst#register_routes

I'll need to add documentation of the Response object (and Response.html() and Response.text() class methods - I should add Response.json() too) to the internals page https://datasette.readthedocs.io/en/stable/internals.html

I'm going to implement this one documentation-first in a pull request.

I'm going to imitate register_output_renderer and register_facet_classes - both return a list of things to register.

So I'll do this:

python @hookspec def register_routes(): "Register URL routes. Return a list of (regex, view_function) pairs"

Here's why:

https://github.com/simonw/datasette/blob/49d6d2f7b0f6cb02e25022e1c9403811f1fa0a7c/datasette/app.py#L1024-L1029

404 errors are rendered by looking for a template from ["404.html", "500.html"].

404.html doesn't actually ship with Datasette (plugins or custom template directories can provide it). So the 500.html template is used.

That template extends base.html, which expects there to be base_url and app_css_hash variables. But as you can see in the excerpt above, those variables are not being passed to the template context when the error page is rendered.

Clue: https://latest.datasette.io/404 displays correctly but https://latest.datasette.io/fixtures/404 does not.

That's because <link rel="stylesheet" href="-/static/app.css?"> does the correct thing if you are on the root of the site but not if you are in a sub-directory.

Documentation: https://datasette.readthedocs.io/en/latest/authentication.html#controlling-the-ability-to-execute-arbitrary-sql