issue_comments
39 rows where "updated_at" is on date 2020-06-18
This data as json, CSV (advanced)
Suggested facets: issue, updated_at (date)
| id ▼ | html_url | issue_url | node_id | user | created_at | updated_at | author_association | body | reactions | issue | performed_via_github_app |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 645781482 | https://github.com/simonw/datasette/issues/852#issuecomment-645781482 | https://api.github.com/repos/simonw/datasette/issues/852 | MDEyOklzc3VlQ29tbWVudDY0NTc4MTQ4Mg== | simonw 9599 | 2020-06-18T05:24:55Z | 2020-06-18T05:25:00Z | OWNER | Question about this on Twitter: https://twitter.com/amjithr/status/1273440766862352384 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | canned_queries() plugin hook 640917326 | |
| 645785830 | https://github.com/simonw/datasette/issues/852#issuecomment-645785830 | https://api.github.com/repos/simonw/datasette/issues/852 | MDEyOklzc3VlQ29tbWVudDY0NTc4NTgzMA== | simonw 9599 | 2020-06-18T05:37:00Z | 2020-06-18T05:37:00Z | OWNER | The easiest way to do this would be with a new plugin hook: def canned_queries(datasette, database): """Return a list of canned query definitions or an awaitable function that returns them" Another approach would be to make the whole of `metadata.json` customizable by plugins. I think I like the dedicated `canned_queries` option better. I'm not happy with the way metadata keeps growing - see #493 - so adding a dedicated hook would be more future proof against other changes I might make to the metadata mechanism. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | canned_queries() plugin hook 640917326 | |
| 646140022 | https://github.com/simonw/datasette/issues/853#issuecomment-646140022 | https://api.github.com/repos/simonw/datasette/issues/853 | MDEyOklzc3VlQ29tbWVudDY0NjE0MDAyMg== | simonw 9599 | 2020-06-18T16:21:53Z | 2020-06-18T16:21:53Z | OWNER | I have a test that demonstrates this working, but also demonstrates that the CSRF protection from #798 makes this really tricky to work with. I'd like to improve that. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Ensure register_routes() works for POST 640943441 | |
| 646151706 | https://github.com/simonw/datasette/issues/835#issuecomment-646151706 | https://api.github.com/repos/simonw/datasette/issues/835 | MDEyOklzc3VlQ29tbWVudDY0NjE1MTcwNg== | simonw 9599 | 2020-06-18T16:36:23Z | 2020-06-18T16:36:23Z | OWNER | Tweeted about this here: https://twitter.com/simonw/status/1273655053170077701 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Mechanism for skipping CSRF checks on API posts 637363686 | |
| 646172200 | https://github.com/simonw/datasette/issues/835#issuecomment-646172200 | https://api.github.com/repos/simonw/datasette/issues/835 | MDEyOklzc3VlQ29tbWVudDY0NjE3MjIwMA== | simonw 9599 | 2020-06-18T16:57:45Z | 2020-06-18T16:57:45Z | OWNER | I think there are a couple of steps to this one. The nature of CSRF is that it's about hijacking existing authentication credentials. If your Datasette site runs without any authentication plugins at all CSRF protection isn't actually useful. Some POST endpoints should be able to opt-out of CSRF protection entirely. A writable canned query that accepts anonymous poll submissions for example might determine that CSRF is not needed. If a plugin adds `Authorization: Bearer xxx` token support that plugin should also be able to specify that CSRF protection can be skipped. https://github.com/simonw/datasette-auth-tokens could do this. This means I need two new mechanisms: - A way for wrapped views to indicate "actually don't CSRF protect me". I'm not sure how feasible this is without a major redesign, since the decision to return a 403 forbidden status is made before the wrapped function has even been called. - A way for authentication plugins like `datasette-auth-tokens` to say "CSRF protection is not needed for this request". This is a bit tricky too, since right now the `actor_from_request` hook doesn't have a channel for information other than returning the actor dictionary. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Mechanism for skipping CSRF checks on API posts 637363686 | |
| 646175055 | https://github.com/simonw/datasette/issues/835#issuecomment-646175055 | https://api.github.com/repos/simonw/datasette/issues/835 | MDEyOklzc3VlQ29tbWVudDY0NjE3NTA1NQ== | simonw 9599 | 2020-06-18T17:00:45Z | 2020-06-18T17:00:45Z | OWNER | Here's the Rails pattern for this: https://gist.github.com/maxivak/a25957942b6c21a41acd | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Mechanism for skipping CSRF checks on API posts 637363686 | |
| 646204308 | https://github.com/simonw/datasette/issues/835#issuecomment-646204308 | https://api.github.com/repos/simonw/datasette/issues/835 | MDEyOklzc3VlQ29tbWVudDY0NjIwNDMwOA== | simonw 9599 | 2020-06-18T17:32:41Z | 2020-06-18T17:32:41Z | OWNER | The only way I can think of for a view to opt-out of CSRF protection is for them to be able to reconfigure the `asgi-csrf` middleware to skip specific URL patterns. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Mechanism for skipping CSRF checks on API posts 637363686 | |
| 646209520 | https://github.com/simonw/datasette/issues/835#issuecomment-646209520 | https://api.github.com/repos/simonw/datasette/issues/835 | MDEyOklzc3VlQ29tbWVudDY0NjIwOTUyMA== | simonw 9599 | 2020-06-18T17:39:30Z | 2020-06-18T17:40:53Z | OWNER | `datasette-auth-tokens` could switch to using `asgi_wrapper` instead of `actor_from_request` - then it could add a `scope["skip_csrf"] = True` scope property to indicate that CSRF should not be protected. Since `asgi_wrapper` wraps the CSRF protection middleware changes made to the `scope` by an `asgi_wrapper` will be visible to the CSRF middleware: https://github.com/simonw/datasette/blob/d2aef9f7ef30fa20b1450cd181cf803f44fb4e21/datasette/app.py#L877-L888 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Mechanism for skipping CSRF checks on API posts 637363686 | |
| 646214158 | https://github.com/simonw/datasette/issues/835#issuecomment-646214158 | https://api.github.com/repos/simonw/datasette/issues/835 | MDEyOklzc3VlQ29tbWVudDY0NjIxNDE1OA== | simonw 9599 | 2020-06-18T17:48:45Z | 2020-06-18T17:48:45Z | OWNER | I wonder if it's safe to generically say "Don't do CSRF protection on any request that includes a `Authorization: Bearer...` header - because it's not possible for a regular browser to send that header since the format is different from the header used in browser-based HTTP basic auth? | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Mechanism for skipping CSRF checks on API posts 637363686 | |
| 646216934 | https://github.com/simonw/datasette/issues/835#issuecomment-646216934 | https://api.github.com/repos/simonw/datasette/issues/835 | MDEyOklzc3VlQ29tbWVudDY0NjIxNjkzNA== | simonw 9599 | 2020-06-18T17:54:14Z | 2020-06-18T17:54:14Z | OWNER | > if you did Origin based CSRF checks, then could the absence of an Origin header be used? https://twitter.com/cnorthwood/status/1273674392757829632 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Mechanism for skipping CSRF checks on API posts 637363686 | |
| 646217766 | https://github.com/simonw/datasette/issues/835#issuecomment-646217766 | https://api.github.com/repos/simonw/datasette/issues/835 | MDEyOklzc3VlQ29tbWVudDY0NjIxNzc2Ng== | simonw 9599 | 2020-06-18T17:55:54Z | 2020-06-18T17:56:04Z | OWNER | Idea: a mechanism where the `asgi_csrf()` can take an optional `should_protect()` callback function which gets called with the `scope` and decides if the current request should be protected or not. It can then look at headers and paths and suchlike and make its own decisions. Datasette could then provide a `should_protect()` callback which can interact with plugins. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Mechanism for skipping CSRF checks on API posts 637363686 | |
| 646218809 | https://github.com/simonw/datasette/issues/820#issuecomment-646218809 | https://api.github.com/repos/simonw/datasette/issues/820 | MDEyOklzc3VlQ29tbWVudDY0NjIxODgwOQ== | simonw 9599 | 2020-06-18T17:58:02Z | 2020-06-18T17:58:02Z | OWNER | I had the same idea again ten days later: #852. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Idea: Plugin hook for registering canned queries 635049296 | |
| 646238702 | https://github.com/simonw/datasette/issues/842#issuecomment-646238702 | https://api.github.com/repos/simonw/datasette/issues/842 | MDEyOklzc3VlQ29tbWVudDY0NjIzODcwMg== | simonw 9599 | 2020-06-18T18:39:07Z | 2020-06-18T18:39:07Z | OWNER | It would be nice if Datasette didn't have to do any additional work to find e.g. `_request_ip` if that parameter turned out not to be used by the query. Could I do this with a custom class that implements `__getitem__()` and then gets passed as SQLite arguments? | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Magic parameters for canned queries 638212085 | |
| 646242172 | https://github.com/simonw/datasette/issues/842#issuecomment-646242172 | https://api.github.com/repos/simonw/datasette/issues/842 | MDEyOklzc3VlQ29tbWVudDY0NjI0MjE3Mg== | simonw 9599 | 2020-06-18T18:46:06Z | 2020-06-18T18:53:31Z | OWNER | Yes that can work - and using `__missing__` (new in Python 3) is nicer because then the regular dictionary gets checked first: ```python import sqlite3 conn = sqlite3.connect(":memory:") class Magic(dict): def __missing__(self, key): return key.upper() conn.execute("select :name", Magic()).fetchall() ``` Outputs: ``` [('NAME',)] ``` | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Magic parameters for canned queries 638212085 | |
| 646246062 | https://github.com/simonw/datasette/issues/842#issuecomment-646246062 | https://api.github.com/repos/simonw/datasette/issues/842 | MDEyOklzc3VlQ29tbWVudDY0NjI0NjA2Mg== | simonw 9599 | 2020-06-18T18:54:41Z | 2020-06-18T18:54:41Z | OWNER | The `_actor_id` param makes this a bit trickier, because we can't just say "if you see an unknown parameter called X call this function" - our magic parameter logic isn't adding single parameters, it might add a whole family of them. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Magic parameters for canned queries 638212085 | |
| 646264051 | https://github.com/simonw/datasette/issues/842#issuecomment-646264051 | https://api.github.com/repos/simonw/datasette/issues/842 | MDEyOklzc3VlQ29tbWVudDY0NjI2NDA1MQ== | simonw 9599 | 2020-06-18T19:32:13Z | 2020-06-18T19:32:37Z | OWNER | If every magic parameter has a prefix and suffix, like `_request_ip` and `_actor_id`, then plugins could register a function for a prefix. Register a function to `_actor` and `actor("id")`will be called for `_actor_id`. But does it make sense for every magic parameter to be of form `_a_b`? I think so. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Magic parameters for canned queries 638212085 | |
| 646272627 | https://github.com/simonw/datasette/issues/842#issuecomment-646272627 | https://api.github.com/repos/simonw/datasette/issues/842 | MDEyOklzc3VlQ29tbWVudDY0NjI3MjYyNw== | simonw 9599 | 2020-06-18T19:51:32Z | 2020-06-18T19:51:32Z | OWNER | I'd be OK with the first version of this not including a plugin hook. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Magic parameters for canned queries 638212085 | |
| 646273035 | https://github.com/simonw/datasette/issues/807#issuecomment-646273035 | https://api.github.com/repos/simonw/datasette/issues/807 | MDEyOklzc3VlQ29tbWVudDY0NjI3MzAzNQ== | simonw 9599 | 2020-06-18T19:52:28Z | 2020-06-18T19:52:28Z | OWNER | I'd like this soon, because I want to start experimenting with things like #852 and #842 without shipping those plugin hooks in a full stable release. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Ability to ship alpha and beta releases 632843030 | |
| 646276150 | https://github.com/simonw/datasette/issues/807#issuecomment-646276150 | https://api.github.com/repos/simonw/datasette/issues/807 | MDEyOklzc3VlQ29tbWVudDY0NjI3NjE1MA== | simonw 9599 | 2020-06-18T19:59:17Z | 2020-06-18T19:59:17Z | OWNER | Relevant PEP: https://www.python.org/dev/peps/pep-0440/ Django's implementation dates back 8 years: https://github.com/django/django/commit/40f0ecc56a23d35c2849f8e79276f6d8931412d1 From the PEP: > Implicit pre-release number > > Pre releases allow omitting the numeral in which case it is implicitly assumed to be 0. The normal form for this is to include the 0 explicitly. This allows versions such as 1.2a which is normalized to 1.2a0. I'm going to habitually include the 0. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Ability to ship alpha and beta releases 632843030 | |
| 646277155 | https://github.com/simonw/datasette/issues/807#issuecomment-646277155 | https://api.github.com/repos/simonw/datasette/issues/807 | MDEyOklzc3VlQ29tbWVudDY0NjI3NzE1NQ== | simonw 9599 | 2020-06-18T20:01:31Z | 2020-06-18T20:01:31Z | OWNER | I thought I might have to update a regex (my CircleCI configs won't match on `a0`, [example](https://github.com/simonw/datasette-publish-now/blob/420f349b278857f62183d8e9835d64f116758be7/.circleci/config.yml#L22)) but it turns out Travis is currently configured to treat ALL tags as potential releases: https://github.com/simonw/datasette/blob/6151c25a5a8d566c109af296244b9267c536bd9a/.travis.yml#L21-L35 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Ability to ship alpha and beta releases 632843030 | |
| 646277680 | https://github.com/simonw/datasette/issues/807#issuecomment-646277680 | https://api.github.com/repos/simonw/datasette/issues/807 | MDEyOklzc3VlQ29tbWVudDY0NjI3NzY4MA== | simonw 9599 | 2020-06-18T20:02:42Z | 2020-06-18T20:02:42Z | OWNER | So I think if I push a tag of `0.45a0` everything might just work - Travis will build it, push the build to PyPI, PyPI won't treat it as a stable release. Except... I don't want to push alphas as Docker images - so I need to fix this code: https://github.com/simonw/datasette/blob/6151c25a5a8d566c109af296244b9267c536bd9a/.travis.yml#L34-L43 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Ability to ship alpha and beta releases 632843030 | |
| 646278801 | https://github.com/simonw/datasette/issues/807#issuecomment-646278801 | https://api.github.com/repos/simonw/datasette/issues/807 | MDEyOklzc3VlQ29tbWVudDY0NjI3ODgwMQ== | simonw 9599 | 2020-06-18T20:05:18Z | 2020-06-18T20:05:18Z | OWNER | Travis conditions documentation: https://docs.travis-ci.com/user/conditions-v1 These look useful: ``` branch =~ /^(one|two)-three$/ (tag =~ ^v) AND (branch = master) ``` | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Ability to ship alpha and beta releases 632843030 | |
| 646279280 | https://github.com/simonw/datasette/issues/807#issuecomment-646279280 | https://api.github.com/repos/simonw/datasette/issues/807 | MDEyOklzc3VlQ29tbWVudDY0NjI3OTI4MA== | simonw 9599 | 2020-06-18T20:06:24Z | 2020-06-18T20:06:24Z | OWNER | So maybe this condition is right? if: (tag IS present) AND NOT (tag =~ [ab]) | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Ability to ship alpha and beta releases 632843030 | |
| 646279428 | https://github.com/simonw/datasette/issues/807#issuecomment-646279428 | https://api.github.com/repos/simonw/datasette/issues/807 | MDEyOklzc3VlQ29tbWVudDY0NjI3OTQyOA== | simonw 9599 | 2020-06-18T20:06:43Z | 2020-06-18T20:06:43Z | OWNER | I'm going to try this on a separate repository so I don't accidentally publish a Datasette release I didn't mean to publish! | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Ability to ship alpha and beta releases 632843030 | |
| 646280134 | https://github.com/simonw/datasette/issues/807#issuecomment-646280134 | https://api.github.com/repos/simonw/datasette/issues/807 | MDEyOklzc3VlQ29tbWVudDY0NjI4MDEzNA== | simonw 9599 | 2020-06-18T20:08:15Z | 2020-06-18T20:08:15Z | OWNER | https://github.com/simonw/datasette-render-images uses Travis and is low-risk for trying this out. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Ability to ship alpha and beta releases 632843030 | |
| 646288146 | https://github.com/simonw/datasette/issues/835#issuecomment-646288146 | https://api.github.com/repos/simonw/datasette/issues/835 | MDEyOklzc3VlQ29tbWVudDY0NjI4ODE0Ng== | simonw 9599 | 2020-06-18T20:26:22Z | 2020-06-18T20:26:31Z | OWNER | Useful tip from Carlton Gibson: https://twitter.com/carltongibson/status/1273680590672453632 > DRF makes ALL views CSRF exempt and then enforces CSRF if you're using Session auth only. > > View: https://github.com/encode/django-rest-framework/blob/e18e40d6ae42457f60ca9c68054ad40d15ba8433/rest_framework/views.py#L144 > Auth: https://github.com/encode/django-rest-framework/blob/e18e40d6ae42457f60ca9c68054ad40d15ba8433/rest_framework/authentication.py#L130 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Mechanism for skipping CSRF checks on API posts 637363686 | |
| 646290171 | https://github.com/simonw/datasette/issues/807#issuecomment-646290171 | https://api.github.com/repos/simonw/datasette/issues/807 | MDEyOklzc3VlQ29tbWVudDY0NjI5MDE3MQ== | simonw 9599 | 2020-06-18T20:30:48Z | 2020-06-18T20:30:48Z | OWNER | OK, I just shipped 0.2a0 of `datasette-render-images` - https://pypi.org/project/datasette-render-images/ has no indication of that: <img width="1330" alt="Banners_and_Alerts_and_datasette-render-images_·_PyPI" src="https://user-images.githubusercontent.com/9599/85068682-acf97980-b167-11ea-863d-a169bd64c25a.png"> But this page does: https://pypi.org/project/datasette-render-images/#history <img width="1382" alt="Banners_and_Alerts_and_datasette-render-images_·_PyPI" src="https://user-images.githubusercontent.com/9599/85068736-c1d60d00-b167-11ea-801b-ebfc4fddbbed.png"> And https://pypi.org/project/datasette-render-images/0.2a0/ exists. In a fresh virtual environment `pip install datasette-render-images` gets 0.1. `pip install datasette-render-images==0.2a0` gets 0.2a0. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Ability to ship alpha and beta releases 632843030 | |
| 646291309 | https://github.com/simonw/datasette/issues/807#issuecomment-646291309 | https://api.github.com/repos/simonw/datasette/issues/807 | MDEyOklzc3VlQ29tbWVudDY0NjI5MTMwOQ== | simonw 9599 | 2020-06-18T20:33:31Z | 2020-06-18T20:33:31Z | OWNER | One more experiment: I'm going to ship `datasette-render-images` 0.2 and see if that works correctly - including printing out the new debug section I put in the Travis config here: https://github.com/simonw/datasette-render-images/blob/6b5f22dab75ca364f671f5597556d2665a251bd8/.travis.yml#L35-L39 - which should demonstrate if my conditional for pushing to Docker Hub will work or not. In the alpha releasing run on Travis that echo statement did NOT execute: https://travis-ci.com/github/simonw/datasette-render-images/builds/172116625 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Ability to ship alpha and beta releases 632843030 | |
| 646292578 | https://github.com/simonw/datasette/issues/807#issuecomment-646292578 | https://api.github.com/repos/simonw/datasette/issues/807 | MDEyOklzc3VlQ29tbWVudDY0NjI5MjU3OA== | simonw 9599 | 2020-06-18T20:36:22Z | 2020-06-18T20:36:22Z | OWNER | https://travis-ci.com/github/simonw/datasette-render-images/builds/172118541 demonstrates that the alpha/beta conditional is working as intended: <img width="1066" alt="Banners_and_Alerts_and_Build__13_-_simonw_datasette-render-images_-_Travis_CI" src="https://user-images.githubusercontent.com/9599/85069271-b0413500-b168-11ea-8a40-7fe2ff0389b2.png"> | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Ability to ship alpha and beta releases 632843030 | |
| 646293029 | https://github.com/simonw/datasette/issues/807#issuecomment-646293029 | https://api.github.com/repos/simonw/datasette/issues/807 | MDEyOklzc3VlQ29tbWVudDY0NjI5MzAyOQ== | simonw 9599 | 2020-06-18T20:37:28Z | 2020-06-18T20:37:46Z | OWNER | Here's the Read The Docs documentation on versioned releases: https://docs.readthedocs.io/en/stable/versions.html It looks like they do the right thing: > We in fact are parsing your tag names against the rules given by PEP 440. This spec allows “normal” version numbers like 1.4.2 as well as pre-releases. An alpha version or a release candidate are examples of pre-releases and they look like this: 2.0a1. > > We only consider non pre-releases for the stable version of your documentation. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Ability to ship alpha and beta releases 632843030 | |
| 646293670 | https://github.com/simonw/datasette/issues/807#issuecomment-646293670 | https://api.github.com/repos/simonw/datasette/issues/807 | MDEyOklzc3VlQ29tbWVudDY0NjI5MzY3MA== | simonw 9599 | 2020-06-18T20:38:50Z | 2020-06-18T20:38:50Z | OWNER | https://pypi.org/project/datasette-render-images/#history worked: <img width="904" alt="Banners_and_Alerts_and_datasette-render-images_·_PyPI" src="https://user-images.githubusercontent.com/9599/85069459-02825600-b169-11ea-9747-cb24e26888d1.png"> I'm now confident enough that I'll make these changes and ship an alpha of Datasette itself. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Ability to ship alpha and beta releases 632843030 | |
| 646302909 | https://github.com/simonw/datasette/issues/807#issuecomment-646302909 | https://api.github.com/repos/simonw/datasette/issues/807 | MDEyOklzc3VlQ29tbWVudDY0NjMwMjkwOQ== | simonw 9599 | 2020-06-18T21:00:02Z | 2020-06-18T21:00:02Z | OWNER | Alpha release is running through Travis now: https://travis-ci.org/github/simonw/datasette/builds/699864168 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Ability to ship alpha and beta releases 632843030 | |
| 646303240 | https://github.com/simonw/datasette/issues/807#issuecomment-646303240 | https://api.github.com/repos/simonw/datasette/issues/807 | MDEyOklzc3VlQ29tbWVudDY0NjMwMzI0MA== | simonw 9599 | 2020-06-18T21:00:41Z | 2020-06-18T21:00:41Z | OWNER | New documentation about the alpha/beta releases: https://datasette.readthedocs.io/en/latest/contributing.html#contributing-alpha-beta | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Ability to ship alpha and beta releases 632843030 | |
| 646307083 | https://github.com/simonw/datasette/issues/835#issuecomment-646307083 | https://api.github.com/repos/simonw/datasette/issues/835 | MDEyOklzc3VlQ29tbWVudDY0NjMwNzA4Mw== | simonw 9599 | 2020-06-18T21:09:35Z | 2020-06-18T21:09:35Z | OWNER | So maybe one really easy fix here is to disable CSRF checks entirely for any request that doesn't have any cookies? Also suggested here: https://twitter.com/mrkurt/status/1273682965168603137 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Mechanism for skipping CSRF checks on API posts 637363686 | |
| 646308467 | https://github.com/simonw/datasette/issues/835#issuecomment-646308467 | https://api.github.com/repos/simonw/datasette/issues/835 | MDEyOklzc3VlQ29tbWVudDY0NjMwODQ2Nw== | simonw 9599 | 2020-06-18T21:12:50Z | 2020-06-18T21:12:50Z | OWNER | Problem there is Login CSRF attacks: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#login-csrf - I still want to perform CSRF checks on login forms, even though the user may not yet have any cookies. Maybe I can turn off CSRF checks for cookie-free requests but allow login forms to specifically opt back in to CSRF protection? | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Mechanism for skipping CSRF checks on API posts 637363686 | |
| 646319315 | https://github.com/simonw/datasette/issues/807#issuecomment-646319315 | https://api.github.com/repos/simonw/datasette/issues/807 | MDEyOklzc3VlQ29tbWVudDY0NjMxOTMxNQ== | simonw 9599 | 2020-06-18T21:38:56Z | 2020-06-18T21:38:56Z | OWNER | This worked! https://pypi.org/project/datasette/#history <img width="924" alt="Banners_and_Alerts_and_datasette_·_PyPI" src="https://user-images.githubusercontent.com/9599/85074185-fd290980-b170-11ea-86b9-eebf8a30e94e.png"> https://github.com/simonw/datasette/releases/tag/0.45a0 is my manually created GitHub prerelease. https://datasette.readthedocs.io/en/latest/changelog.html#a0-2020-06-18 has the release notes. A shame Read The Docs doesn't seem to build the docs for these releases -it's not showing the tag in the releases pane here: <img width="323" alt="Changelog_—_Datasette_documentation" src="https://user-images.githubusercontent.com/9599/85074331-39f50080-b171-11ea-99b9-c70f8a89727b.png"> Also the new tag isn't an option in the Build menu on https://readthedocs.org/projects/datasette/builds/ Not a big problem though since the "latest" tag on Read The Docs will still carry the in-development documentation. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Ability to ship alpha and beta releases 632843030 | |
| 646320237 | https://github.com/simonw/datasette/issues/807#issuecomment-646320237 | https://api.github.com/repos/simonw/datasette/issues/807 | MDEyOklzc3VlQ29tbWVudDY0NjMyMDIzNw== | simonw 9599 | 2020-06-18T21:41:16Z | 2020-06-18T21:41:16Z | OWNER | https://pypi.org/project/datasette/0.45a0/ is the release on PyPI. And in a fresh virtual environment: ``` $ pip install datasette==0.45a0 ... $ datasette --version datasette, version 0.45a0 ``` But running `pip install datasette` still gets 0.44. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Ability to ship alpha and beta releases 632843030 | |
| 646329456 | https://github.com/simonw/datasette/issues/852#issuecomment-646329456 | https://api.github.com/repos/simonw/datasette/issues/852 | MDEyOklzc3VlQ29tbWVudDY0NjMyOTQ1Ng== | simonw 9599 | 2020-06-18T22:07:09Z | 2020-06-18T22:07:37Z | OWNER | It would be neat if the queries returned by this hook could be restricted to specific users. I think I can do that by returning an "allow" block as part of the query. But... what if we allow users to save private queries and we might have thousands of users each with hundreds of saved queries? For that case it would be good if the plugin hook could take an optional `actor` parameter. This would also allow us to dynamically generate a canned query for "return the bookmarks belonging to this actor" or similar! | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | canned_queries() plugin hook 640917326 | |
| 646350530 | https://github.com/simonw/datasette/issues/852#issuecomment-646350530 | https://api.github.com/repos/simonw/datasette/issues/852 | MDEyOklzc3VlQ29tbWVudDY0NjM1MDUzMA== | simonw 9599 | 2020-06-18T23:13:57Z | 2020-06-18T23:14:11Z | OWNER | ```python @hookspec def canned_queries(datasette, database, actor): "Return a dictionary of canned query definitions or an awaitable function that returns them" ``` | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | canned_queries() plugin hook 640917326 |
Advanced export
JSON shape: default, array, newline-delimited, object
CREATE TABLE [issue_comments] (
[html_url] TEXT,
[issue_url] TEXT,
[id] INTEGER PRIMARY KEY,
[node_id] TEXT,
[user] INTEGER REFERENCES [users]([id]),
[created_at] TEXT,
[updated_at] TEXT,
[author_association] TEXT,
[body] TEXT,
[reactions] TEXT,
[issue] INTEGER REFERENCES [issues]([id])
, [performed_via_github_app] TEXT);
CREATE INDEX [idx_issue_comments_issue]
ON [issue_comments] ([issue]);
CREATE INDEX [idx_issue_comments_user]
ON [issue_comments] ([user]);