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 hacke…
This 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.
Show HN: Hasura – A Postgres BaaS and Kubernetes PaaS on Your Own Infrastructure
51–60 of 72 posts
Re: Show HN: Hasura – A Postgres BaaS and Kubernetes PaaS on Your Own Infrastructure
#52Earlier quoted context omitted.
This 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.
I 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?
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.
Re: Show HN: Hasura – A Postgres BaaS and Kubernetes PaaS on Your Own Infrastructure
#53Looks kinda like Dokku + PostgREST + a fancy UI, is that mostly right? Not trying to disparage it, just trying to relate figure out what Hasura is, there's a lot going on. One thing that concerns me is the "Don't make changes to your Postgres schema outside of the UI, it'll mess things up" warning. If I already have a tool to manage database migrations, it sounds like using it with this would be a bad idea? Edit: Als…
(I'm from postgrest core team, probably competing with hasura in the future here https://graphqlapi.com)
Re: Show HN: Hasura – A Postgres BaaS and Kubernetes PaaS on Your Own Infrastructure
#54Looks kinda like Dokku + PostgREST + a fancy UI, is that mostly right? Not trying to disparage it, just trying to relate figure out what Hasura is, there's a lot going on. One thing that concerns me is the "Don't make changes to your Postgres schema outside of the UI, it'll mess things up" warning. If I already have a tool to manage database migrations, it sounds like using it with this would be a bad idea? Edit: Als…
Actually Hasura is something that might be the only thing out there that is anything close to touching postgrest in this space (respect :)). The only thing that worries me a bit is that the client can generate any type of query, meaning it's easy to generate an unoptimized join that will kill the db (did i get it wrong? how do you protect against that?). The other thing i do not understand is why are you not relying…
Well actually we do infer directly from the Postgres schema. Only for users not familiar with Postgres directly, we recommend going through the UI so that not only is the table created, but the Data API is also asked to track it and provide an API for it.
There is other metadata that we do need the user to specify, via the UI or the API, and that's for stuff like permissions and relationships.
Regarding, the unrestricted querying, we address it in one of the following ways:
1. Timing out queries running for longer than a specified interval.
2. Cursors and streaming data if the dataset requested is large.
3. Query templates: We allow the developer to create a RESTful API endpoint that has a limited pre-defined surface area (eg: GET data.mysite.com/v1/template/article?limit=10) which internally maps to a pre-defined query.
Our docs are still lagging behind on these unfortunately!
What do you guys do to restrict access? Any suggestions?
Re: Show HN: Hasura – A Postgres BaaS and Kubernetes PaaS on Your Own Infrastructure
#55Re: Show HN: Hasura – A Postgres BaaS and Kubernetes PaaS on Your Own Infrastructure
#56Earlier quoted context omitted.
Actually Hasura is something that might be the only thing out there that is anything close to touching postgrest in this space (respect :)). The only thing that worries me a bit is that the client can generate any type of query, meaning it's easy to generate an unoptimized join that will kill the db (did i get it wrong? how do you protect against that?). The other thing i do not understand is why are you not relying…
Hey there! Thanks for your comment. Well actually we do infer directly from the Postgres schema. Only for users not familiar with Postgres directly, we recommend going through the UI so that not only is the table created, but the Data API is also asked to track it and provide an API for it. There is other metadata that we do need the user to specify, via the UI or the API, and that's for stuff like permissions and re…
timing out - it works up to a point, if you for example set a hard limit to 1s then to an attacker it just means he needs to do a few parallel requests and he still kills your db.
what postgrest does for protection: a - no fancy joins, joins are only done by a thing we call "embedding" and those are joins between tables that FKs defined between them so they are fast, if you need fancy joins then the user has to define the view doing the join and expose it to the api.
b - no functions applied to the return columns, like you cant generate something like "select md5(bigtextcolumn) ..."
c - the only way to "kill" the database under postgrest is to use a filter on a column that has no index ( name like "hello"), out of the box postgrest does not have protection build in for that, but it's easy to put a proxy in front and whenever there is a url parameter called "name" you just reply with "you are not allowed to filter by this column"
Re: Show HN: Hasura – A Postgres BaaS and Kubernetes PaaS on Your Own Infrastructure
#57Earlier quoted context omitted.
Hey there! Thanks for your comment. Well actually we do infer directly from the Postgres schema. Only for users not familiar with Postgres directly, we recommend going through the UI so that not only is the table created, but the Data API is also asked to track it and provide an API for it. There is other metadata that we do need the user to specify, via the UI or the API, and that's for stuff like permissions and re…
about metadata: in Postgrest - you tell it which schema to expose and that means that anything inside it needs "tracking" and exposing, want it exposed, put it in that schema. Relations between entities ... that can be queried from the database itself, no need to ask the user for it. timing out - it works up to a point, if you for example set a hard limit to 1s then to an attacker it just means he needs to do a few p…
Re: Show HN: Hasura – A Postgres BaaS and Kubernetes PaaS on Your Own Infrastructure
#58We built Hasura over the last few years to help us build products fast. We didn't know what it would look like when we started, but we've ended up with something like a Parse + Heroku but on your own infra so that you can mess around with the internals when required. Key features: 1. Data APIs on a Postgres database 2. Deploy with git-push, or any docker image 3. Expose HTTP services on the API gateway over subdomain…
One minor nit: It is quite nice that you provide links to jump to the right place for each step, but I would suggest adding images of the equivalent spot to click in the UI.
So, what's the registration code?
Re: Show HN: Hasura – A Postgres BaaS and Kubernetes PaaS on Your Own Infrastructure
#59We built Hasura over the last few years to help us build products fast. We didn't know what it would look like when we started, but we've ended up with something like a Parse + Heroku but on your own infra so that you can mess around with the internals when required. Key features: 1. Data APIs on a Postgres database 2. Deploy with git-push, or any docker image 3. Expose HTTP services on the API gateway over subdomain…
In the comparison page, it would be great to see how Hasura compares to other PAAS offerings, such as Deis, Flynn, Tsuru, etc. Agreed that built in ACLs and Baas is really fantastic.
Re: Show HN: Hasura – A Postgres BaaS and Kubernetes PaaS on Your Own Infrastructure
#60Earlier quoted context omitted.
In the comparison page, it would be great to see how Hasura compares to other PAAS offerings, such as Deis, Flynn, Tsuru, etc. Agreed that built in ACLs and Baas is really fantastic.
Thanks! The BaaS components and the session middleware are precisely what differentiates Hasura from the above platforms.