id,node_id,number,title,user,state,locked,assignee,milestone,comments,created_at,updated_at,closed_at,author_association,pull_request,body,repo,type,active_lock_reason,performed_via_github_app,reactions,draft,state_reason
628089318,MDU6SXNzdWU2MjgwODkzMTg=,787,"""datasette publish"" should bake in a random --secret",9599,closed,0,,5512395,1,2020-06-01T01:15:26Z,2020-06-11T16:02:05Z,2020-06-11T16:02:05Z,OWNER,,"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",107914493,issue,,,"{""url"": ""https://api.github.com/repos/simonw/datasette/issues/787/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed
628499086,MDU6SXNzdWU2Mjg0OTkwODY=,790,"""flash messages"" mechanism",9599,closed,0,,5512395,20,2020-06-01T14:55:44Z,2020-06-08T19:33:59Z,2020-06-02T21:14:03Z,OWNER,,"> 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_",107914493,issue,,,"{""url"": ""https://api.github.com/repos/simonw/datasette/issues/790/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed
628087971,MDU6SXNzdWU2MjgwODc5NzE=,786,Documentation page describing Datasette's authentication system,9599,closed,0,,5512395,2,2020-06-01T01:10:06Z,2020-06-06T19:40:20Z,2020-06-06T19:40:20Z,OWNER,,_Originally posted by @simonw in https://github.com/simonw/datasette/issues/699#issuecomment-636562999_,107914493,issue,,,"{""url"": ""https://api.github.com/repos/simonw/datasette/issues/786/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed
628121234,MDU6SXNzdWU2MjgxMjEyMzQ=,788, /-/permissions debugging tool,9599,closed,0,,5512395,2,2020-06-01T03:13:47Z,2020-06-06T00:43:40Z,2020-06-01T05:01:01Z,OWNER,,"> 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_",107914493,issue,,,"{""url"": ""https://api.github.com/repos/simonw/datasette/issues/788/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed