[HN Gopher] GraphQLize: JVM library to build GraphQL API instant...
___________________________________________________________________
GraphQLize: JVM library to build GraphQL API instantly from
PostgreSQL and MySQL
Author : tamizh88
Score : 34 points
Date : 2020-03-18 20:41 UTC (2 hours ago)
(HTM) web link (www.graphqlize.org)
(TXT) w3m dump (www.graphqlize.org)
| mooted1 wrote:
| For the love of god, this is never how GraphQL was intended to be
| used. The official graphql website is very clear:
|
| https://graphql.org/learn/authorization/
|
| > Delegate authorization logic to the business logic layer
|
| If you take security or performance debugging seriously, you
| should never expose database models through APIs directly in a
| production app.
|
| To illustrate, say you have an Employee model:
| query { employee(userId=uuid) { name
| salary } }
|
| Say you add some hacks on top of this to only allow users to
| query their own employee data, believing this provides adequate
| security.
|
| The next day, someone creates a Manager object, a relation from
| employee to Manager, and Manager to employee.
|
| Now, without having consider security for a second, you've
| granted all employees the ability to query each other:
| query { employee(userId=uuid) { name
| salary manager { employees {
| name salary }
| } } }
|
| To say that these problems occur in the wild frequently is an
| understatement. Since these graphql frameworks also expose
| introspection capabilities, discovering these exploits can be
| automated using crawlers. If you write a bug like this, and you
| will, people will find it.
|
| Please, please stop encouraging people to directly expose their
| databases through an API.
| rattray wrote:
| The solution to this should be to use the db's
| security/permissions model.
|
| For example, with postgres:
| https://stackoverflow.com/questions/49261452/combining-row-l...
| dvasdekis wrote:
| I agree that this is indeed a problem, but your proposed cure
| is unnecessarily onerous. At least with Hasura's equivalent
| product, allowing queries on related objects is an opt-in
| process for the admin, after each related object is defined.
|
| I think a better piece of advice is: Please stop allowing
| people to query relational models automatically, and surface a
| separate locked-down schema for the GraphQL user.
|
| These GraphQL over DB tools have real value. I've moved from
| using OpenResty to Hasura in order to surface Postgres APIs,
| and the time saved has been significant.
| willvarfar wrote:
| I have been planning a graphql adapter for presto, so we can
| query graphql apis as though they were sql tables.
|
| I guess it is inevitable that somehow some sql database will be
| exposed via graphql, and someone will use something like presto
| to make it appear to be an SQL database again...
| meritt wrote:
| I understand this stuff is "cool" but this is only one step
| removed from db->query(input[sql]). I'm not talking about SQL
| injection either, I'm talking about wholesale data exfiltration
| of your entire database because you've auto-generated some slick
| GraphQL API and you don't take the time to think through what
| should, and should not, be exposed to end users or bother to
| implement any form of access control.
| cjoelrun wrote:
| Interested in comparing with Postgraphile. Besides JVM vs
| TypeScript.
| cjoelrun wrote:
| Looks like early day project. Had this exact project in mind
| when working with Postgraphile. JVM tooling around databases
| are amazing. Using clojure on top of that foundation with
| honey-sql was something I wish existed. Good luck! I might look
| into helping build it someday.
| haolez wrote:
| Nice! Is it stable enough for production? Or at least as stable
| as PostgREST?
| lysium wrote:
| No. The web page says he expects it to be ready in a few
| months.
___________________________________________________________________
(page generated 2020-03-18 23:00 UTC)