4 ms·

> "client should only be able to query objects the user account has access to" > "client should only be able to perform certain kinds of transactions and mutat

> "client should only be able to query objects the user account has access to" > "client should only be able to perform certain kinds of transactions and mutations" The solution to these is equal for server rendered HTML containing {data} or an API just getting {data} in raw form - the request contains an access token which identifies and authorises the user - same goes for mutations on {data}. The answer to the question 'how do you know who the user is when they request a server rendered page containing some sensitive data?' is literally the copy/paste solution to how to do authentication on your API - as in, it's basically the same code that must be implemented on the backend in either case :-) The point is it's the same data and mutations, just a different interface over them. There is no security tradeoff of using one over the other.

abraae 6y ago
> it's basically the same code that must be implemented on the backend in either case :-) No, it's not. If I expose an API e.g GET /widgets,I need to ensure that there is no combination of parameters that will ever return a widget that the user should not see (e.g because it belongs to some other department). Whereas when I render a web page server side, I just need to write a single, correct, SQL statement that pulls in the widgets that this specific web page requires.
- davnicwil 6y ago
  I respectfully disagree: it's the same code, moved around a bit of course, but literally the same logic making whatever conditional statements or database calls necessary to do permissions :-) It's the same data, with the same auth needed. If it's accessible to anyone over the network you need auth for everyone in either model. The auth code is the same code in either model, only the interface changes. Looking at your example to illustrate: you have user A and user B, who have permission to see different types of widgets depending on what department they belong to. -- Scenario 1: filtering per-resource There is a server-rendered /widgets page that lists all widgets, filtering based on what types of widgets the requesting user can see. API implementation: /widgets endpoint that returns a list of all widgets for the client to render. It must filter based on what type of widgets the requesting user can see, so that only widgets they can see are included in the list. Same logic as above. -- Scenario 2: grouping resources and authenticating at entry There are different server rendered pages for each department, listing all widgets for that department: /widgets/foo-dept, /widgets/bar-dept. You must check the permissions on the requesting user before rendering the page, to see if they have access. If user A can't see foo widgets, you give them some kind of permissions error when they request the /widgets/foo-dept page. API implementation: Add a dept param to the /widgets endpoint that lists only widgets in the specified department. If dept param is populated, check that the requesting user has permissions to see widgets in that department. If they do, proceed, if not, throw a permissions error and deal with it on the client to produce the exact same UI as in the server rendered example. Same logic as above. -- If you have resources accessible over the network, and you do auth on them based on user attributes, you have to do that auth either way, regardless of if you're server rendering the data into HTML pages or returning it as JSON or whatever else and rendering the HTML on the client.
  - tdeck 6y ago
    I'm really struggling in this thread because it seems like folks are either missing one half of my point or the other half. The idea was that I have to either a) duplicate effort in both my frontend and backend (that's extra work), or b) have no security at all. The goal of both applications is to display HTML. The duplicated work in an SPA is in the DB API -> JSON API and JSON API -> page steps. These steps involve telling my backend server about how my data are structured and how to interpret them, translating them to JSON (or something else), then telling my frontend the same things. Every SPA I have seen involves doing this work, although some (like Meteor) are designed to reduce it as much as possible. That's the standard work involved in an SPA. The second half of my point is that you could remove this duplicate work but doing that gets rid of any security. Why is this? Let's look at my SQL API example again. In this example, I have effectively eliminated the duplicate work of making my app server aware of the data's schema. It just runs a query, serializes the blob that comes back, and returns it. So why not do that? Obviously because now I'm trusting the client too much. In a non-SPA world it's fine to trust the entity making queries (for the most part...let's not get derailed). In the SPA world it's not, so we inject the app server in between to do mediation, and we pay the cost.
- MaxBarraclough 6y ago
  A web API doesn't have to be general and reusable. It could be tailored to specific pages, if that's what makes more sense.
  - tdeck 6y ago
    Very true, but in an l evolving application you often pay the cost of that approach because any small change to the data displayed or the behavior of the application will require a change to both frontend and backend (e.g. wiring up a new API), so in practice I think people tend to build in a certain amount of generality. It's a kind of trade-off between the time to design a more general API vs. the time to churn the existing API when we tweak the application.
- sunaurus 6y ago
  You're exposing an API in both cases. In one case, your API returns HTML, in the other case, it returns (presumably) JSON. The format of the response doesn't have to have any bearing on what SQL queries you write or what permissions you check - you can implement the data fetching exactly the same way for both cases.
Fradow 6y ago
In an ideal world, probably, or using {insert technology here} that does that natively, yes. In my experience, it hasn't been the case: designing a REST API (I know REST complexifies the API compared to tailored RCP) that behaves properly for the client is magnitude more work than rendering HTML with data server-side. The main difference is switching the question from "what does this page needs to render for this user", to "what are all the things the front-end might want to access through this API for this user, and how do the front-end plan on filtering". The former is obviously easier to answer, and as the result easier to code.
- davnicwil 6y ago
  I agree 100%, and it all depends on what problem you're solving for. For the 80% case of having an API which just serves one or a few of your own clients with their UIs architected into broadly similar views, I basically just go for an additive model of providing a default RESTful API but then additional view-specific, and then if necessary even client-specific, endpoints on top where this makes sense. Honestly most of the time you can even just cut out the REST layer except where it overlaps with views by coincidence. For instance in practice there are quite a lot of views which simply get a single resource, or list a single type of resource with paging. For mutations I am a big fan of just doing it RPC-style. I know it's not to everyone's taste but I feel like abstracting mutations out behind a model of RESTful resources and verbs is, 99% of the time, a waste of time, the notable edge case being where you truly need a flexible API for 3rd parties (both apps with UIs and scripts) where organising functionality in this completely generic flexible way - with the considerable extra effort that you mention being the price to pay - has huge payoff.
tdeck 6y ago
> The answer to the question 'how do you know who the user is when they request a server rendered page containing some sensitive data?' is literally the copy/paste solution to how to do authentication on your API - as in, it's basically the same code that must be implemented on the backend in either case :-) 100% agree. But that (authentication) is not what this thread is about. > The point is it's the same data and mutations, just a different interface over them. There is no security tradeoff of using one over the other. 100% agree again. A properly written application makes no security trade-off here by using an API. But that's because a properly written SPA stack does the work of interpreting the data and it's relationships twice on both the frontend and backend.

abraae 6y ago

> it's basically the same code that must be implemented on the backend in either case :-) No, it's not. If I expose an API e.g GET /widgets,I need to ensure that there is no combination of parameters that will ever return a widget that the user should not see (e.g because it belongs to some other department). Whereas when I render a web page server side, I just need to write a single, correct, SQL statement that pulls in the widgets that this specific web page requires.

davnicwil 6y ago
I respectfully disagree: it's the same code, moved around a bit of course, but literally the same logic making whatever conditional statements or database calls necessary to do permissions :-) It's the same data, with the same auth needed. If it's accessible to anyone over the network you need auth for everyone in either model. The auth code is the same code in either model, only the interface changes. Looking at your example to illustrate: you have user A and user B, who have permission to see different types of widgets depending on what department they belong to. -- Scenario 1: filtering per-resource There is a server-rendered /widgets page that lists all widgets, filtering based on what types of widgets the requesting user can see. API implementation: /widgets endpoint that returns a list of all widgets for the client to render. It must filter based on what type of widgets the requesting user can see, so that only widgets they can see are included in the list. Same logic as above. -- Scenario 2: grouping resources and authenticating at entry There are different server rendered pages for each department, listing all widgets for that department: /widgets/foo-dept, /widgets/bar-dept. You must check the permissions on the requesting user before rendering the page, to see if they have access. If user A can't see foo widgets, you give them some kind of permissions error when they request the /widgets/foo-dept page. API implementation: Add a dept param to the /widgets endpoint that lists only widgets in the specified department. If dept param is populated, check that the requesting user has permissions to see widgets in that department. If they do, proceed, if not, throw a permissions error and deal with it on the client to produce the exact same UI as in the server rendered example. Same logic as above. -- If you have resources accessible over the network, and you do auth on them based on user attributes, you have to do that auth either way, regardless of if you're server rendering the data into HTML pages or returning it as JSON or whatever else and rendering the HTML on the client.
- tdeck 6y ago
  I'm really struggling in this thread because it seems like folks are either missing one half of my point or the other half. The idea was that I have to either a) duplicate effort in both my frontend and backend (that's extra work), or b) have no security at all. The goal of both applications is to display HTML. The duplicated work in an SPA is in the DB API -> JSON API and JSON API -> page steps. These steps involve telling my backend server about how my data are structured and how to interpret them, translating them to JSON (or something else), then telling my frontend the same things. Every SPA I have seen involves doing this work, although some (like Meteor) are designed to reduce it as much as possible. That's the standard work involved in an SPA. The second half of my point is that you could remove this duplicate work but doing that gets rid of any security. Why is this? Let's look at my SQL API example again. In this example, I have effectively eliminated the duplicate work of making my app server aware of the data's schema. It just runs a query, serializes the blob that comes back, and returns it. So why not do that? Obviously because now I'm trusting the client too much. In a non-SPA world it's fine to trust the entity making queries (for the most part...let's not get derailed). In the SPA world it's not, so we inject the app server in between to do mediation, and we pay the cost.
MaxBarraclough 6y ago
A web API doesn't have to be general and reusable. It could be tailored to specific pages, if that's what makes more sense.
- tdeck 6y ago
  Very true, but in an l evolving application you often pay the cost of that approach because any small change to the data displayed or the behavior of the application will require a change to both frontend and backend (e.g. wiring up a new API), so in practice I think people tend to build in a certain amount of generality. It's a kind of trade-off between the time to design a more general API vs. the time to churn the existing API when we tweak the application.
sunaurus 6y ago
You're exposing an API in both cases. In one case, your API returns HTML, in the other case, it returns (presumably) JSON. The format of the response doesn't have to have any bearing on what SQL queries you write or what permissions you check - you can implement the data fetching exactly the same way for both cases.

Fradow 6y ago

In an ideal world, probably, or using {insert technology here} that does that natively, yes. In my experience, it hasn't been the case: designing a REST API (I know REST complexifies the API compared to tailored RCP) that behaves properly for the client is magnitude more work than rendering HTML with data server-side. The main difference is switching the question from "what does this page needs to render for this user", to "what are all the things the front-end might want to access through this API for this user, and how do the front-end plan on filtering". The former is obviously easier to answer, and as the result easier to code.

davnicwil 6y ago
I agree 100%, and it all depends on what problem you're solving for. For the 80% case of having an API which just serves one or a few of your own clients with their UIs architected into broadly similar views, I basically just go for an additive model of providing a default RESTful API but then additional view-specific, and then if necessary even client-specific, endpoints on top where this makes sense. Honestly most of the time you can even just cut out the REST layer except where it overlaps with views by coincidence. For instance in practice there are quite a lot of views which simply get a single resource, or list a single type of resource with paging. For mutations I am a big fan of just doing it RPC-style. I know it's not to everyone's taste but I feel like abstracting mutations out behind a model of RESTful resources and verbs is, 99% of the time, a waste of time, the notable edge case being where you truly need a flexible API for 3rd parties (both apps with UIs and scripts) where organising functionality in this completely generic flexible way - with the considerable extra effort that you mention being the price to pay - has huge payoff.

tdeck 6y ago

> The answer to the question 'how do you know who the user is when they request a server rendered page containing some sensitive data?' is literally the copy/paste solution to how to do authentication on your API - as in, it's basically the same code that must be implemented on the backend in either case :-) 100% agree. But that (authentication) is not what this thread is about. > The point is it's the same data and mutations, just a different interface over them. There is no security tradeoff of using one over the other. 100% agree again. A properly written application makes no security trade-off here by using an API. But that's because a properly written SPA stack does the work of interpreting the data and it's relationships twice on both the frontend and backend.