4 ms·

Okay. Tell me how you do the control/auth and allow certain users to access a resource while others do not access it while they may formulate complex queries wh

by x86x87 3y ago

Okay. Tell me how you do the control/auth and allow certain users to access a resource while others do not access it while they may formulate complex queries where they ask for the kitchen sink.

andrewingram 3y ago
By wrapping the code that loads data with code that checks whether the current (i.e. requesting) user is allowed to load that data. I don't really understand the problem, how is this any more difficult than any other API paradigm?
- foota 3y ago
  I think the additional issues come when you want to define access by a relationship instead of just the entity, which means you need to check access based on the edges, and not the nodes. You'd have to do this anyway with REST, but I think it's easier in some ways to make mistakes and allow more access than intended.
pravus 3y ago
I honestly don't understand the complaints here. In our deployment it's implemented as an HTTP handler right next to all the REST ones and gets all of the standard authz/authn/obervability wrappers. It's allowed us to focus more on core development because the schema was exported over a year ago and hasn't changed much. It functions almost identically to the REST components but is easier to develop against. No issues with scale or performance that aren't apparent in the REST components either.
tomtheelder 3y ago
Honestly there’s a few good ways to do that. Schema directives, regular old permission system at the resolver level, etc. I’m not a big fan of GraphQL, but I it’s not particularly difficult to secure.
seanp2k2 3y ago
https://konghq.com/blog/engineering/graphql-authorization-at-the-api-gateway-with-kong-konnect-and-opa https://konghq.com/blog/engineering/graphql-authorization-at... has a pretty comprehensive look into one way to handle auth with Kong. I believe Envoy can do something similar. It’s not as easy as an htaccess with regex on routes but it’s not impossible.
ewalk153 3y ago
This is handled at the library level, typically. For example in graphql-ruby, it’s built in [1] [1] https://graphql-ruby.org/authorization/visibility.html https://graphql-ruby.org/authorization/visibility.html
deecewan 3y ago
> Tell me how you do the control/auth and allow certain users to access a resource while others how would you do this with REST? or any other kind of API? graphql, at it's core, is a tool for the frontend to describe to the backend what data it wants. how the backend replies to that is completely up to the backend. > formulate complex queries where they ask for the kitchen sink most concrete implementations i've seen include a way to limit complexity. in `graphql-ruby` for example, you can limit how many nodes, and you can apply a "cost" to a particularly expensive-to-calculate node if you like. Say you give an API only 10 "complexity points". You could make most nodes cost 1 point, and expensive nodes cost 3 points. Now, someone can _request_ the kitchen sink, but you can respond with a "no".

by x86x87 3y ago

Okay. Tell me how you do the control/auth and allow certain users to access a resource while others do not access it while they may formulate complex queries where they ask for the kitchen sink.

andrewingram 3y ago

By wrapping the code that loads data with code that checks whether the current (i.e. requesting) user is allowed to load that data. I don't really understand the problem, how is this any more difficult than any other API paradigm?

foota 3y ago
I think the additional issues come when you want to define access by a relationship instead of just the entity, which means you need to check access based on the edges, and not the nodes. You'd have to do this anyway with REST, but I think it's easier in some ways to make mistakes and allow more access than intended.

pravus 3y ago

I honestly don't understand the complaints here. In our deployment it's implemented as an HTTP handler right next to all the REST ones and gets all of the standard authz/authn/obervability wrappers. It's allowed us to focus more on core development because the schema was exported over a year ago and hasn't changed much. It functions almost identically to the REST components but is easier to develop against. No issues with scale or performance that aren't apparent in the REST components either.

tomtheelder 3y ago

Honestly there’s a few good ways to do that. Schema directives, regular old permission system at the resolver level, etc. I’m not a big fan of GraphQL, but I it’s not particularly difficult to secure.

seanp2k2 3y ago

https://konghq.com/blog/engineering/graphql-authorization-at-the-api-gateway-with-kong-konnect-and-opa https://konghq.com/blog/engineering/graphql-authorization-at... has a pretty comprehensive look into one way to handle auth with Kong. I believe Envoy can do something similar. It’s not as easy as an htaccess with regex on routes but it’s not impossible.

ewalk153 3y ago

This is handled at the library level, typically. For example in graphql-ruby, it’s built in [1] [1] https://graphql-ruby.org/authorization/visibility.html https://graphql-ruby.org/authorization/visibility.html

deecewan 3y ago

> Tell me how you do the control/auth and allow certain users to access a resource while others how would you do this with REST? or any other kind of API? graphql, at it's core, is a tool for the frontend to describe to the backend what data it wants. how the backend replies to that is completely up to the backend. > formulate complex queries where they ask for the kitchen sink most concrete implementations i've seen include a way to limit complexity. in `graphql-ruby` for example, you can limit how many nodes, and you can apply a "cost" to a particularly expensive-to-calculate node if you like. Say you give an API only 10 "complexity points". You could make most nodes cost 1 point, and expensive nodes cost 3 points. Now, someone can _request_ the kitchen sink, but you can respond with a "no".