home / github

Menu
  • Search all tables
  • GraphQL API

issue_comments

Table actions
  • GraphQL API for issue_comments

13 rows where "updated_at" is on date 2021-06-06 sorted by updated_at descending

✖
✖

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: issue_url, created_at (date), updated_at (date)

user 2

  • simonw 12
  • dracos 1

issue 2

  • Consider using CSP to protect against future XSS 12
  • Support cross-database joins 1

author_association 2

  • OWNER 12
  • NONE 1
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions issue performed_via_github_app
855430317 https://github.com/simonw/datasette/issues/1362#issuecomment-855430317 https://api.github.com/repos/simonw/datasette/issues/1362 MDEyOklzc3VlQ29tbWVudDg1NTQzMDMxNw== simonw 9599 2021-06-06T17:07:48Z 2021-06-06T17:07:48Z OWNER

I guess I can offer a disable_csp setting so that people with complex custom templates aren't completely blocked from using them with Datasette, but maybe it would be better not to offer that? Or to offer it as a datasette-insecure-csp plugin instead?

I like the idea of very actively encouraging CSP across all Datasette projects, but I'm nervous about making the software unusable for certain edge cases.

Maybe require CSP and wait for someone to complain?

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Consider using CSP to protect against future XSS 912864936  
855429111 https://github.com/simonw/datasette/issues/1362#issuecomment-855429111 https://api.github.com/repos/simonw/datasette/issues/1362 MDEyOklzc3VlQ29tbWVudDg1NTQyOTExMQ== simonw 9599 2021-06-06T16:59:05Z 2021-06-06T17:00:15Z OWNER

Twitter conversation: https://twitter.com/simonw/status/1401565566045806594

@dracos provided some really useful code examples there:

We generate it here: https://github.com/mysociety/fixmystreet/blob/e9fec4e567e7148ed128816e5770c2963be51af6/perllib/FixMyStreet/Cobrand/Default.pm#L89-L90 And use it e.g. https://github.com/mysociety/fixmystreet/blob/ba6788cd25d8f471a4e3308403607627b4d2f4f6/templates/web/base/common_header_tags.html or https://github.com/mysociety/fixmystreet/blob/cb4f2b96364d151988b5c664888468b25cc62240/templates/web/fixmystreet.com/header/css.html

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Consider using CSP to protect against future XSS 912864936  
855428601 https://github.com/simonw/datasette/issues/1362#issuecomment-855428601 https://api.github.com/repos/simonw/datasette/issues/1362 MDEyOklzc3VlQ29tbWVudDg1NTQyODYwMQ== simonw 9599 2021-06-06T16:55:33Z 2021-06-06T16:55:33Z OWNER

No, because Vary header is about request headers that cause the response to vary, not response headers.

Hah, of course! Thanks for the correction. So the nonce mechanism would actually be pretty great here, especially for the extra_body_script() hook.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Consider using CSP to protect against future XSS 912864936  
855428296 https://github.com/simonw/datasette/issues/1362#issuecomment-855428296 https://api.github.com/repos/simonw/datasette/issues/1362 MDEyOklzc3VlQ29tbWVudDg1NTQyODI5Ng== dracos 154364 2021-06-06T16:53:20Z 2021-06-06T16:53:20Z NONE

Presumably this would also require adding Content-Security-Policy to the Vary header though, which will have a nasty effect on Cloudflare and Fastly and such like.

No, because Vary header is about request headers that cause the response to vary, not response headers.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Consider using CSP to protect against future XSS 912864936  
855427396 https://github.com/simonw/datasette/issues/1362#issuecomment-855427396 https://api.github.com/repos/simonw/datasette/issues/1362 MDEyOklzc3VlQ29tbWVudDg1NTQyNzM5Ng== simonw 9599 2021-06-06T16:46:17Z 2021-06-06T16:46:17Z OWNER

Mind you, since that plugin hook looks like this:

python @hookimpl def extra_body_script(): return { "module": True, "script": "console.log('Your JavaScript goes here...')" } Having it calculate a sha256 hash wouldn't be difficult.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Consider using CSP to protect against future XSS 912864936  
855426750 https://github.com/simonw/datasette/issues/1362#issuecomment-855426750 https://api.github.com/repos/simonw/datasette/issues/1362 MDEyOklzc3VlQ29tbWVudDg1NTQyNjc1MA== simonw 9599 2021-06-06T16:41:30Z 2021-06-06T16:44:49Z OWNER

This is from the current base.html template: https://github.com/simonw/datasette/blob/030deb4b25cda842ff7129ab7c18550c44dd8379/datasette/templates/base.html#L62-L66

Which includes this: https://github.com/simonw/datasette/blob/030deb4b25cda842ff7129ab7c18550c44dd8379/datasette/templates/_close_open_menus.html#L1-L16

The body_scripts bit is for this extra_body_script plugin hook, which is the thing that will be the most affected by implementing CSP: https://docs.datasette.io/en/stable/plugin_hooks.html#extra-body-script-template-database-table-columns-view-name-request-datasette

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Consider using CSP to protect against future XSS 912864936  
855426516 https://github.com/simonw/datasette/issues/1362#issuecomment-855426516 https://api.github.com/repos/simonw/datasette/issues/1362 MDEyOklzc3VlQ29tbWVudDg1NTQyNjUxNg== simonw 9599 2021-06-06T16:39:34Z 2021-06-06T16:39:34Z OWNER

The reason Datasette uses small inline scripts right now is to avoid the overhead of an extra HTTP request for a JavaScript file - but these are both inherently cachable and perform much better under HTTP/2 so that's likely a false optimization.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Consider using CSP to protect against future XSS 912864936  
855426314 https://github.com/simonw/datasette/issues/1362#issuecomment-855426314 https://api.github.com/repos/simonw/datasette/issues/1362 MDEyOklzc3VlQ29tbWVudDg1NTQyNjMxNA== simonw 9599 2021-06-06T16:38:04Z 2021-06-06T16:38:04Z OWNER

The other option for inline scripts is the CSP nonce:

Content-Security-Policy: script-src 'nonce-2726c7f26c'

Then:

<script nonce="2726c7f26c">
  var inline = 1;
</script>

Since an attacker can't guess what the nonce will be it prevents them from injecting their own script block - this seems easier to make available to plugins than a full hashing mechanism, just make {{ csp_nonce() }} available to the template.

That template function can then be smart enough to set a flag which Datasette uses to decide if the script-src 'nonce-2726c7f26c' policy should be sent or not.

Presumably this would also require adding Content-Security-Policy to the Vary header though, which will have a nasty effect on Cloudflare and Fastly and such like.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Consider using CSP to protect against future XSS 912864936  
855418899 https://github.com/simonw/datasette/issues/1362#issuecomment-855418899 https://api.github.com/repos/simonw/datasette/issues/1362 MDEyOklzc3VlQ29tbWVudDg1NTQxODg5OQ== simonw 9599 2021-06-06T15:42:55Z 2021-06-06T15:42:55Z OWNER

Another consideration: testing that this works correctly could require adoption of a real browser test environment (probably Cypress or maybe Playwright) to execute tests that will fail if CSP is violated.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Consider using CSP to protect against future XSS 912864936  
855418698 https://github.com/simonw/datasette/issues/1362#issuecomment-855418698 https://api.github.com/repos/simonw/datasette/issues/1362 MDEyOklzc3VlQ29tbWVudDg1NTQxODY5OA== simonw 9599 2021-06-06T15:41:24Z 2021-06-06T15:41:24Z OWNER

I think the best way to answer these questions is with some prototyping - of both Datasette and some of the existing JavaScript plugins.

I can start with a datasette-experimental-csp plugin that sets the header (and could even run an optional report URI mechanism).

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Consider using CSP to protect against future XSS 912864936  
855418401 https://github.com/simonw/datasette/issues/1362#issuecomment-855418401 https://api.github.com/repos/simonw/datasette/issues/1362 MDEyOklzc3VlQ29tbWVudDg1NTQxODQwMQ== simonw 9599 2021-06-06T15:39:38Z 2021-06-06T15:39:38Z OWNER

The security benefit of forcing all JavaScript plugins to be written as CSP-friendly external scripts is very compelling though.

Other plugin-heavy ecosystems such as WordPress have suffered greatly from insecurely written plugins - could this be a huge security win for the Datasette ecosystem generally?

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Consider using CSP to protect against future XSS 912864936  
855418065 https://github.com/simonw/datasette/issues/1362#issuecomment-855418065 https://api.github.com/repos/simonw/datasette/issues/1362 MDEyOklzc3VlQ29tbWVudDg1NTQxODA2NQ== simonw 9599 2021-06-06T15:37:11Z 2021-06-06T15:37:11Z OWNER

The easiest way to apply CSP is to remove all inline <script> blocks (Datasette has a few) and instead serve JavaScript as separate linked files.

It's possible to keep inline script blocks by calculating a hash of their content and adding a Content-Security-Policy: script-src 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8=' to the policy. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src

This could be achieved with some Django template tricks, but it feels very risky - and done carelessly could end up calculating a hash of a reflected XSS attack!

The biggest challenge I see around here involves plugins and custom templates. Adopting CSP would require plugins to avoid using any inline scripts, instead keeping their entire implementations in .js files.

That's maybe not a bad thing, but it represents a big commitment. It would need to be adopted before Datasette 1.0.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Consider using CSP to protect against future XSS 912864936  
855369819 https://github.com/simonw/datasette/issues/283#issuecomment-855369819 https://api.github.com/repos/simonw/datasette/issues/283 MDEyOklzc3VlQ29tbWVudDg1NTM2OTgxOQ== simonw 9599 2021-06-06T09:40:18Z 2021-06-06T09:40:18Z OWNER

One note on using this pragma I got an error on starting datasette no such table: pragma_database_list.

I diagnosed this to an older version of sqlite3 (3.14.2) and upgrading to a newer version (3.34.2) fixed the issue.

That issue is fixed in #1276.

{
    "total_count": 1,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 1,
    "rocket": 0,
    "eyes": 0
}
Support cross-database joins 325958506  

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options:

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]);
Powered by Datasette · Queries took 1273.511ms · About: github-to-sqlite
  • Sort ascending
  • Sort descending
  • Facet by this
  • Hide this column
  • Show all columns
  • Show not-blank rows