4 ms·
One of the features, that I know how to do in MongoDB quickly but not in Postgres, is creating permissions not on the the role level (user, admin, etc) but on t
by ojr 10y ago
One of the features, that I know how to do in MongoDB quickly but not in Postgres, is creating permissions not on the the role level (user, admin, etc) but on the id level like users with unique id blah234 and blah546 can access this table/row. I can figure it out in sql with time but it is not a tradeoff worth taking in my certain situation. I always look for this feature when I see a baas/paas tool show up on hacker news.
- amalag 10y agoIf you know the multiple id's, why not make a role for them?
- ojr 10y agoI don't know them
- ecthiender 10y agoThis is quite possible with the permission layer of the data service in Hasura. Why not add a new role that only 'blah234' and 'blah546' can be part of? All you have to do is to define permissions on this role. Also, creating permissions and roles are all exposed via API calls, in case you have a requirement where you need to create these dynamically.
- ojr 10y agoI looked into an api, I don't see how can leverage it in the way I want, yes these roles will have to be created dynamically, pretend a user makes a post and only wants certain users to see the post, a new dynamic role will have to be created every time a user creates a new post?
- tango12 10y agoYou could do that, but you don't need to. The ACL constraint can be any arbitrary SQLish expression that is a boolean. In this case, say select is allowed if: req_user_id is in article.viewers.user_id. This means, if the request's user_id is in the viewers list of the article. It depends on the fact, that you have a relationship called viewers which comes from a table that contains article_id, user_id. The idea is to allow any ACL rule that can be represented as a constraint in your data model.