issues

I'm going to draw the line here: default Datasette supports authentication but only for a single user account ("admin"). Plugins can then add support for multiple user accounts, social auth, SSO etc.

Originally posted by @simonw in https://github.com/simonw/datasette/issues/699#issuecomment-636498770

See also milestone. This is a pretty big release: flash messaging, writable canned queries, authentication and permissions!

I'll want to ship some plugin releases in conjunction with this - datasette-auth-github for example.

https://travis-ci.org/github/simonw/datasette/jobs/697445318 ``` def test_plugin_config_file(app_client): open(TEMP_PLUGIN_SECRET_FILE, "w").write("FROM_FILE")

  assert {"foo": "FROM_FILE"} == app_client.ds.plugin_config("file-plugin")

E AssertionError: assert {'foo': 'FROM_FILE'} == {'foo': {'$fi...ugin-secret'}} E Differing items: E {'foo': 'FROM_FILE'} != {'foo': {'$file': '/tmp/plugin-secret'}} E Use -v to get the full diff ``` Broken in https://github.com/simonw/datasette/commit/fba8ff6e76253af2b03749ed8dd6e28985a7fb8f as part of #837

This didn't work: json { "plugins": { "datasette-auth-tokens": [ { "token": { "$env": "BOT_TOKEN" }, "actor": { "bot_id": "my-bot" } } ] } }

https://github.com/simonw/datasette-auth-github/issues/62 will work for this.

actor: {"id": "root"}

allow block: {"bot_id": "my-bot", "id": ["root"]}

This should pass, because the id matches - but it fails.

The only URLs that should be available without authentication at all times are the /-/static/ prefix, to allow for HTTP caching.

Refs #787. Will need quite a bit of manual testing since this involves code which runs against Heroku and Cloud Run.

To allow signed cookies etc to work reliably (see #785) all of the datasette publish commands should generate a random secret on publish and bake it into the configuration - probably by setting the DATASETTE_SECRET environment variable.

• [ ] Cloud Run
• [ ] Heroku
• [ ] https://github.com/simonw/datasette-publish-now
• [ ] https://github.com/simonw/datasette-publish-fly

To show how they work. Also useful to confirm how they interact with the default permissions.

Now that I'm starting to write alternative plugins to control permissions - see #818 - I think I need an easy way to tell Datasette "no-one has permission to do X unless a plugin says otherwise".

One relatively intuitive way to do that could be like this:

json { "databases": { "fixtures": { "allow": null } } }

Right now I think that opens up permissions to everyone, which isn't as obvious.

I need this for datasette-auth-github: https://github.com/simonw/datasette-auth-github/issues/62#issuecomment-642152076

You can scroll sideways on that page and it looks bad:

The cause is these long links:

Mainly to clean up this code:

https://github.com/simonw/datasette/blob/4fa7cf68536628344356d3ef8c92c25c249067a0/datasette/app.py#L439-L454

Most authentication plugins (https://github.com/simonw/datasette-auth-github for example) are likely to work by setting the ds_actor signed cookie, which is already magically decoded and supported by default Datasette here:

https://github.com/simonw/datasette/blob/4fa7cf68536628344356d3ef8c92c25c249067a0/datasette/actor_auth_cookie.py#L1-L13

I should document this.

This command is meant to write out fixtures.db, metadata.json and a plugins directory: $ python tests/fixtures.py /tmp/fixtures.db /tmp/metadata.json /tmp/plugins/ Test tables written to /tmp/fixtures.db - metadata written to /tmp/metadata.json Traceback (most recent call last): File "tests/fixtures.py", line 833, in <module> ("my_plugin.py", PLUGIN1), NameError: name 'PLUGIN1' is not defined

Plugin authors need to know that if they want to POST a form they should include this: html+jinja <input type="hidden" name="csrftoken" value="{{ csrftoken() }}">

I'd like plugins to be able to ship with a default that says "anonymous users cannot do this", but allow site administrators to over-ride that such that anonymous users can use the feature after all.

This is tricky because right now the anonymous user doesn't have an actor dictionary at all, so there's no key to match to an allow block.

Docs at https://github.com/simonw/datasette/blob/5a6a73e3190cac103906b479d56129413e5ef190/docs/authentication.rst#actors say:

The only required field in an actor is "id", which must be a string.

But the example here returns {"token": token}:

```python @hookimpl def actor_from_request(datasette, request): async def inner(): token = request.args.get("_token") if not token: return None # Look up ?_token=xxx in sessions table result = await datasette.get_database().execute( "select count(*) from sessions where token = ?", [token] ) if result.first()[0]: return {"token": token} else: return None

return inner

```

Added here: https://github.com/simonw/datasette/commit/aa82d0370463580f2cb10d9617f1bcbe45cc994a#diff-5e0ffd62fced7d46339b9b2cd167c2f9R236

This example: https://github.com/simonw/datasette/blob/f5e79adf26d0daa3831e3fba022f1b749a9efdee/docs/plugins.rst#register_routes

```python from datasette.utils.asgi import Response import html

async def hello_from(scope): name = scope["url_route"]["kwargs"]["name"] return Response.html("Hello from {}".format( html.escape(name) ))

@hookimpl def register_routes(): return [ (r"^/hello-from/(?P<name>.*)$"), hello_from) ] `` Would be nicer if you could easily getscope["url_route"]["kwargs"]["name"]directly from the request object, without looking at thescope`.

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

Originally posted by @simonw in https://github.com/simonw/datasette/issues/215#issuecomment-640971470

Might be as simple as having plugins get passed the app after the other routes have been defined:

https://github.com/simonw/datasette/blob/b2955d9065ea019500c7d072bcd9d49d1967f051/datasette/app.py#L1270-L1274

Refs #14

Refs #215

e.g. https://latest.datasette.io/fixtures/compound_three_primary_keys.tsv?_size=max

The HTML starts like this:

```html

Split from #811. It would be useful if finely-grained permissions configured in metadata.json could be used to specify if a user is allowed to execute arbitrary SQL queries.

We have a permission check call for this already: https://github.com/simonw/datasette/blob/9397d718345c4b35d2a5c55bfcbd1468876b5ab9/datasette/views/database.py#L159

But there's currently no way to implement this check without writing a plugin.

I think a "allow_sql": {...} block at the database level in metadata.json (sibling to the current "allow" block for that database implemented in #811) would be a good option for this.

No reason not to expand the "allow" mechanism described here to the root of metadata.json plus to databases and tables.

Refs #810 and #800.

json { "databases": { "mydatabase": { "allow": { "id": ["root"] } } } }

TODO:

• [x] Instance level
• [x] Database level
• [x] Table level
• [x] Query level
• [x] Affects list of queries
• [x] Affects list of tables on database page
• [x] Affects truncated list of tables on index page
• [x] Affects list of SQL views on database page
• [x] Affects list of databases on index page
• [x] Show 🔒 in header on index page for private instances
• [x] Show 🔒 in header on private database page
• [x] Show 🔒 in header on private table page
• [x] Show 🔒 in header on private query page
• [x] Move assert_permissions_checked() calls from test_html.py to test_permissions.py
• [x] Update documentation

Passing ?_success like this isn't necessarily the best approach. Potential improvements include:

• Signing this message so it can't be tampered with (I could generate a signing secret on startup)
• Using a cookie with a temporary flash message in it instead
• Using HTML5 history API to remove the ?_success= from the URL bar when the user lands on the page

If I add an option to redirect the user to another page after success I may need a mechanism to show a flash message on that page as well, in which case I'll need a general flash message solution that works for any page.

Originally posted by @simonw in https://github.com/simonw/datasette/pull/703

This example is obsolete, it's from a time before request.actor and authentication as a built-in concept (#699): https://github.com/simonw/datasette/blob/0c064c5fe220b7b3d8dcf85b02b4e60452c47232/docs/plugins.rst#L696-L700

https://github.com/simonw/datasette/blob/0c064c5fe220b7b3d8dcf85b02b4e60452c47232/docs/plugins.rst#extra_template_varstemplate-database-table-view_name-request-datasette

This code here (TODO is follow-on from #808).

https://github.com/simonw/datasette/blob/86dec9e8fffd6c4efec928ae9b5713748dec7e74/datasette/views/database.py#L133-L142

I can improve this with extra code in https://github.com/simonw/datasette/blob/86dec9e8fffd6c4efec928ae9b5713748dec7e74/datasette/default_permissions.py

Idea: default is anyone can execute a query.

Or you can specify the following:

```json

{ "databases": { "my-database": { "queries": { "add_twitter_handle": { "sql": "insert into twitter_handles (username) values (:username)", "write": true, "allow": { "id": ["simon"], "role": ["staff"] } } } } } } `` These get matched against the actor JSON. If any of the fields in any of the keys of"allow"` match a key on the actor, the query is allowed.

"id": "*" matches any actor with an id key.

Originally posted by @simonw in https://github.com/simonw/datasette/issues/698#issuecomment-639784651

Every view in Datasette should perform a permission check to see if the current user/actor is allowed to view that page.

This permission check will default to allowed, but having this check will allow plugins to lock down access selectively or even to everything in a Datasette instance.

Canned queries are currently read-only: https://datasette.readthedocs.io/en/0.38/sql_queries.html#canned-queries

Add a "write": true option to their definition in metadata.json which turns them into queries that are submitted via POST and send their queries to the write queue.

Then they can be used as a really quick way to define a writable interface and JSON API!

Right now Datasette authentication is provided exclusively by plugins:

• https://github.com/simonw/datasette-auth-github
• https://github.com/simonw/datasette-auth-existing-cookies

This is an all-or-nothing approach: either your Datasette instance requires authentication at the top level or it does not.

But... as I build new plugins like https://github.com/simonw/datasette-configure-fts and https://github.com/simonw/datasette-edit-tables I increasingly have individual features which should be reserved for logged-in users while still wanting other parts of Datasette to be open to all.

This is too much for plugins to own independently of Datasette core. Datasette needs to ship a single "user is authenticated" concept (independent of how users actually sign in) so that different plugins can integrate with it.

Originally posted by @simonw in https://github.com/simonw/datasette/issues/699#issuecomment-636562999

The /-/messages debug tool will need CSRF protection or people will be able to add messages using a hidden form on another website. Originally posted by @simonw in https://github.com/simonw/datasette/issues/790#issuecomment-637790860

Refs #793

See comment in https://github.com/simonw/datasette/issues/784#issuecomment-636514974

Datasette needs to be able to set signed cookies - which means it needs a mechanism for safely handling a signing secret.

Since Datasette is a long-running process the default behaviour here can be to create a random secret on startup. This means that if the server restarts any signed cookies will be invalidated.

If the user wants a persistent secret they'll have to generate it themselves - maybe by setting an environment variable?

Debugging tool idea: /-/permissions page which shows you the actor and lets you type in the strings for action, resource_type and resource_identifier - then shows you EVERY plugin hook that would have executed and what it would have said, plus when the chain would have terminated.

Bonus: if you're logged in as the root user (or a user that matches some kind of permission check, maybe a check for permissions_debug) you get to see a rolling log of the last 30 permission checks and what the results were across the whole of Datasette. This should make figuring out permissions policies a whole lot easier.

Originally posted by @simonw in https://github.com/simonw/datasette/issues/699#issuecomment-636576603