3 ms·

> How do you translate access restriction like "user X cannot view more than 10 articles per month" That's not permissions in the general sense of authorisatio

by jseban 4y ago

> How do you translate access restriction like "user X cannot view more than 10 articles per month" That's not permissions in the general sense of authorisation, that should just be modelled as any other "business logic". Put that article_limit in the users table and join it in the selects. Edit: or tracking the users article views with timestamps, and making a select aggregate over the month.. > "customer Y cannot insert any more orders if total outstanding/unpaid amount of invoices in last 30 days succeeds Z" insert into orders select from user a inner join invoices b etc.. any kind of limitless complexity here on how you want to limit the orders.

littlecranky67 4y ago
But if you design a public GraphQL API, you cannot trust the query issuer (Browser or App on the Client). You have to enforce those rules outside of the query. And yes, there is tons of ways to do this outside of GraphQL, which is exactly my point, that row/column permissions alone do not suffice.
- jseban 4y ago
  Ok I get you now, yes you are correct, if you have a public API and you have business constraints that need to be enforced, you have to do this server side. But you can still implement this easily in queries, so for example granting the client only read permissions, plus execution permissions on certain database functions, and inside these functions you can implement the constraints. What I'm trying to say, is that you don't necessarily need any backend "services" java etc, to implement these type of constraints, they can be modelled as any other business logic in the database.
  - rojobuffalo 4y ago
    agreed. i've worked extensively with graphile, and from working with people who were really strong in postgres i learned all the things we needed could be modeled in postgres. many of the less obvious solutions would involve functions, triggers, or stored procedures. but i liked that there was less ambiguity about where that kind of logic was implemented.

by jseban 4y ago

littlecranky67 4y ago

But if you design a public GraphQL API, you cannot trust the query issuer (Browser or App on the Client). You have to enforce those rules outside of the query. And yes, there is tons of ways to do this outside of GraphQL, which is exactly my point, that row/column permissions alone do not suffice.

jseban 4y ago
Ok I get you now, yes you are correct, if you have a public API and you have business constraints that need to be enforced, you have to do this server side. But you can still implement this easily in queries, so for example granting the client only read permissions, plus execution permissions on certain database functions, and inside these functions you can implement the constraints. What I'm trying to say, is that you don't necessarily need any backend "services" java etc, to implement these type of constraints, they can be modelled as any other business logic in the database.
- rojobuffalo 4y ago
  agreed. i've worked extensively with graphile, and from working with people who were really strong in postgres i learned all the things we needed could be modeled in postgres. many of the less obvious solutions would involve functions, triggers, or stored procedures. but i liked that there was less ambiguity about where that kind of logic was implemented.