4 ms·
I understand what GraphQL is: it's a step towards full datastore access on the client side. It exposes some security issues (what if you don't want a user to h
by carsongross 11y ago
I understand what GraphQL is: it's a step towards full datastore access on the client side. It exposes some security issues (what if you don't want a user to have access to some data and miss a security constraint, as you will, and they modify your GraphQL language to see it?) but it isn't the full security clusterfuck.
Yet.
Again, the tradeoff is touching your API (or security model) every time UX needs change, or exposing more and more security issues client side.
- peterhunt 11y agoThat's absolutely not true. For each node type and edge type in the graph, you provide a required canSee() function which controls its visibility. This granular access control leads to a more secure system than the alternative, which is doing access control at the endpoint level and then hoping that the endpoint doesn't fetch data it isn't supposed to.
- phantom_package 11y agoIs canSee() in the spec? Looks useful, but I haven't seen it before (heh).
- carsongross 11y agoGreat question! No, no it is not in the spec, as of February 15th, 2016: http://archive.is/quwUd http://archive.is/quwUd Update: I think Peter Hunt is talking about Facebook's internal server-side implementation of GraphQL. That's the only way his comments make any sense given what's publicly available.
- peterhunt 11y agoIt doesn't belong in the spec, it belongs in the implementation. But yes, the reference implementation (graphql-js) should probably be updated to demonstrate access control.
- carsongross 11y ago> I think you misunderstand what GraphQL is. > For each node type and edge type in the graph, you provide a required canSee() function which controls its visibility. > It doesn't belong in the spec _kek_ Am I on candid camera?