issue_comments

Actually I'm not sure about this. If "allow": null means "no-one can do this", what's the allow block syntax for "everyone can do this"?

It could be "allow": {} - but that's not intuitive because normally the allow block shows keys that need to match. {} suggests to me that no matches are possible.

So I think I'm going to stick with the current mechanism, which is that "allow": null means "anyone can do this" and "allow": {} means "no-one can do this".

datasette-permissions-sql yaml plugins: datasette-permissions-sql: view-instance: |- select count(*) from users where admin = 1 and id = :id

What's a simple but useful plugin I could release that exercises this hook?

Ideally one which executes permission checks against the database somehow.

I could do a simplest-possible implementation of the idea in #801 (allow-by-query).

New policy in 9f236c4 dictates that this should be in Milestone 0.44 after all:

• New plugin hooks should only be shipped if accompanied by a separate release of a non-demo plugin that uses them.

I didn't bother with the alternative epoch - it only shaves off two or three bytes from the cookie.

Documentation for the new ds_actor cookie shape is here: https://datasette.readthedocs.io/en/latest/authentication.html#the-ds-actor-cookie

Even shorter: encode an integer that is the difference between that expiry timestamp and a more recent epoch - June 1st 2020 will do.

```

import datetime, calendar calendar.timegm(datetime.date(2020, 6, 1).timetuple()) 1590969600 import baseconv baseconv.base62.encode(int(time.time() - 1590969600)) '3XST' ```

And the e key can be nullor missing for "never expires".

I'm going with expires_at - except to keep the cookies shorter the key will be called e and the actor will go in a, like this:

json { "e": "1UuHoo", "a": {"id": "root"} } That e value is a base64 encoded expiry integer timestamp (again for a shorter cookie) - using https://pypi.org/project/python-baseconv/

Some options:

• Redesign the ds_actor cookie to be {"expires_at": 1591811250, "actor": ...} - check if it has expired in that default actor_from_request hook
• Let plugins set an additional cookie of some sort
• Expect plugins that care about this to set a cookie with a different name and implement their own actor_from_request against that

itsdangerous has this ability but you specify the max-age when you call unsign: https://itsdangerous.palletsprojects.com/en/1.1.x/timed/

s.unsign(string, max_age=5)
Traceback (most recent call last):
  ...
itsdangerous.exc.SignatureExpired: Signature age 15 > 5 seconds

I currently only decode the ds_actor cookie in one place: https://github.com/simonw/datasette/blob/d828abaddec0dce3ec4b4eeddc3a74384e52cf34/datasette/actor_auth_cookie.py#L5-L12

If plugins want to be able to set their own policies on how long the ds_actor cookie should remain valid, how do I know to listen to them when decoding the cookie here?

There's a working demo here: https://github.com/wragge/datasette-test

And if you want something that's more than just proof-of-concept, here's a notebook which does some harvesting from web archives and then displays the results using Datasette: https://nbviewer.jupyter.org/github/GLAM-Workbench/web-archives/blob/master/explore_presentations.ipynb

Hi,

I came across this issue while looking for a way to spawn Datasette as a SQLite files viewer in JupyterLab. I found https://github.com/simonw/jupyterserverproxy-datasette-demo which seems to be the most up to date proof of concept, but it seems to be failing to list the available db (at least in the Binder demo, https://hub.gke.mybinder.org/user/simonw-jupyters--datasette-demo-uw4dmlnn/datasette/, I only have :memory).

Does anyone tried to improve on this proof of concept to have a Datasette visualization for SQLite files?

Thanks!

Fixed. https://datasette.readthedocs.io/en/latest/changelog.html

https://docs.readthedocs.io/en/stable/guides/adding-custom-css.html

This CSS seems to fix it: css a.external {overflow-wrap: anywhere;}