4 ms·

> 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 th

by 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.

by abraae 6y ago

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.