issue_comments

Documentation: - https://docs.datasette.io/en/latest/authentication.html#controlling-the-ability-to-execute-arbitrary-sql - https://docs.datasette.io/en/latest/settings.html#setting-default-allow-sql

If I was prone to over-thinking (which I am) I'd note that allow_facet and allow_download and allow_csv_stream are all settings that do NOT have an equivalent in the newer permissions system, which is itself a little weird and inconsistent.

So maybe there's a future task where I introduce those as both permissions and metadata "allow_x" blocks, then rename the settings themselves to be called default_allow_facet and default_allow_download and default_allow_csv_stream.

If I was going to do that I should get it in before Datasette 1.0.

I think default_allow_sql is more consistent with the current naming conventions, because both allow and default are used as prefixes at the moment but neither of them are ever used as a suffix.

Plus default_allow_sql off makes sense to me but allow_default_sql off does not - what is "default SQL"?

One of these two options:

• --setting default_allow_sql off
• --setting allow_sql_default off

Existing settings from https://docs.datasette.io/en/0.58.1/settings.html with similar names that I need to be consistent with:

• default_page_size
• allow_facet
• default_facet_size
• allow_download
• default_cache_ttl
• default_cache_ttl_hashed
• allow_csv_stream

My rationale for removing it: https://github.com/simonw/datasette/issues/813#issuecomment-640916290

Naming problem: Datasette already has a config option with this name:

$ datasette serve data.db --config allow_sql:1

https://datasette.readthedocs.io/en/stable/config.html#allow-sql

It's confusing to have two things called allow_sql that do slightly different things.

I could retire the --config allow_sql:0 option entirely, since the new metadata.json mechanism can be used to achieve the exact same thing.

I'm going to do that.

This is true. The "allow_sql" permissions block in metadata.json does indeed have a name that is easily confused with --setting allow_sql off.

So I definitely need to pick a different name from the setting. --setting default_allow_sql off is a good option here.

I think the correct solution is for the default permissions logic to take the allow_sql setting into account, and to return False if that setting is set to off AND the current actor fails the actor_matches_allow checks.

The other option would be to use the setting to pick the default= argument when calling self.ds.permission_allowed( request.actor, "execute-sql", resource=database, default=True).

The problem with that is that there are actually a few different places which perform that check, so changing all of them raises the risk of missing one in the future:

https://github.com/simonw/datasette/blob/a6c8e7fa4cffdeff84e9e755dcff4788fd6154b8/datasette/views/table.py#L436-L444

https://github.com/simonw/datasette/blob/a6c8e7fa4cffdeff84e9e755dcff4788fd6154b8/datasette/views/table.py#L964-L966

https://github.com/simonw/datasette/blob/d23a2671386187f61872b9f6b58e0f80ac61f8fe/datasette/views/database.py#L220-L221

https://github.com/simonw/datasette/blob/d23a2671386187f61872b9f6b58e0f80ac61f8fe/datasette/views/database.py#L343-L345

https://github.com/simonw/datasette/blob/d23a2671386187f61872b9f6b58e0f80ac61f8fe/datasette/views/database.py#L134-L136

I think I can make this modification by teaching the default permissions code here to take the allow_sql setting into account: https://github.com/simonw/datasette/blob/ff253f5242e4b0b5d85d29d38b8461feb5ea997a/datasette/default_permissions.py#L38-L45

I'm going to stick with --setting allow_sql off.

I think I may like disable_sql better. Some options:

• --setting allow_sql off (consistent with allow_facet and allow_download and allow_csv_stream - all which default to on already)
• --setting disable_sql on
• --setting disable_custom_sql on

The existence of three allow_* settings does make a strong argument for staying consistent with that.