issue_comments: 1636093730

This data as json

html_url issue_url id node_id user created_at updated_at author_association body reactions issue performed_via_github_app
https://github.com/simonw/datasette/issues/2102#issuecomment-1636093730 https://api.github.com/repos/simonw/datasette/issues/2102 1636093730 IC_kwDOBm6k_c5hhM8i 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
}
 1805076818