issue_comments
5 rows where author_association = "OWNER" and "created_at" is on date 2023-07-14
This data as json, CSV (advanced)
Suggested facets: created_at (date)
id ▼ | html_url | issue_url | node_id | user | created_at | updated_at | author_association | body | reactions | issue | performed_via_github_app |
---|---|---|---|---|---|---|---|---|---|---|---|
1636036312 | https://github.com/simonw/datasette/issues/2102#issuecomment-1636036312 | https://api.github.com/repos/simonw/datasette/issues/2102 | IC_kwDOBm6k_c5hg-7Y | simonw 9599 | 2023-07-14T15:37:14Z | 2023-07-14T15:37:14Z | OWNER | I think I made this decision because I was thinking about default deny: obviously if a user has been denied access to a database. It doesn't make sense that they could access tables within it. But now that I am spending more time with authentication tokens, which default to denying everything, except for the things that you have explicitly listed, this policy, no longer makes as much sense. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | API tokens with view-table but not view-database/view-instance cannot access the table 1805076818 | |
1636040164 | https://github.com/simonw/datasette/issues/2102#issuecomment-1636040164 | https://api.github.com/repos/simonw/datasette/issues/2102 | IC_kwDOBm6k_c5hg_3k | simonw 9599 | 2023-07-14T15:40:21Z | 2023-07-14T15:40:21Z | OWNER | Relevant code: https://github.com/simonw/datasette/blob/0f7192b6154edb576c41b55bd3f2a3f53e5f436a/datasette/app.py#L822-L855 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | API tokens with view-table but not view-database/view-instance cannot access the table 1805076818 | |
1636042066 | https://github.com/simonw/datasette/issues/2102#issuecomment-1636042066 | https://api.github.com/repos/simonw/datasette/issues/2102 | IC_kwDOBm6k_c5hhAVS | simonw 9599 | 2023-07-14T15:41:54Z | 2023-07-14T15:42:32Z | OWNER | I tried some code spelunking and came across https://github.com/simonw/datasette/commit/d6e03b04302a0852e7133dc030eab50177c37be7 which says: > - If you have table permission but not database permission you can now view the table page Refs: - #832 Which suggests that my initial design decision wasn't what appears to be implemented today. Needs more investigation. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | API tokens with view-table but not view-database/view-instance cannot access the table 1805076818 | |
1636053060 | https://github.com/simonw/datasette/issues/2102#issuecomment-1636053060 | https://api.github.com/repos/simonw/datasette/issues/2102 | IC_kwDOBm6k_c5hhDBE | simonw 9599 | 2023-07-14T15:51:36Z | 2023-07-14T16:14:05Z | OWNER | This might only be an issue with the code that checks `_r` on actors. https://github.com/simonw/datasette/blob/0f7192b6154edb576c41b55bd3f2a3f53e5f436a/datasette/default_permissions.py#L185-L222 Added in https://github.com/simonw/datasette/commit/bcc781f4c50a8870e3389c4e60acb625c34b0317 - refs: - #1855 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | API tokens with view-table but not view-database/view-instance cannot access the table 1805076818 | |
1636093730 | https://github.com/simonw/datasette/issues/2102#issuecomment-1636093730 | https://api.github.com/repos/simonw/datasette/issues/2102 | IC_kwDOBm6k_c5hhM8i | simonw 9599 | 2023-07-14T16:26:27Z | 2023-07-14T16:32:49Z | OWNER | Here's that crucial comment: > If _r is defined then we use those to further restrict the actor. > >Crucially, we only use this to say NO (return False) - we never use it to return YES (True) because that might over-ride other restrictions placed on this actor So that's why I implemented it like this. The goal here is to be able to issue a token which can't do anything _more_ than the actor it is associated with, but CAN be configured to do less. So I think the solution here is for the `_r` checking code to perhaps implement its own view cascade logic - it notices if you have `view-table` and consequently fails to block `view-table` and `view-instance`. I'm not sure that's going to work though - would that mean that granting `view-table` grants `view-database` in a surprising and harmful way? Maybe that's OK: if you have `view-database` but permission checks fail for individual tables and queries you shouldn't be able to see a thing that you shouldn't. Need to verify that though. Also, do `Permission` instances have enough information to implement this kind of cascade without hard-coding anything? | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | API tokens with view-table but not view-database/view-instance cannot access the table 1805076818 |
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]);