4 ms·

Look, kids. You are going to have to have an execution layer you can trust somewhere, you can't just expose your data store directly to the outside world or yo

Look, kids. You are going to have to have an execution layer you can trust somewhere, you can't just expose your data store directly to the outside world or you run into an infinite number of security issues[1]. (Not that this is stopping people from doing exactly this these days.) That somewhere is going to be a server side execution environment, and it will be separate from your data store so you can scale these concerns independently. Additionally, you are probably going to want a DSL for your data access as well as a highly tuned indexing system for your data store. We have systems that do this, they are called databases. Are they perfect? No. Nothing is. But the idea that they have "failed the web" is so over-the-top childish that, like the author says at the end of his post, I'm not inclined to be charitable. [1] - http://intercoolerjs.org/2016/02/17/api-churn-vs-security.html http://intercoolerjs.org/2016/02/17/api-churn-vs-security.ht...

dragonwriter 10y ago
> Look, kids. You are going to have to have an execution layer you can trust somewhere, you can't just expose your data store directly to the outside world or you run into an infinite number of security issues The security issues your source points to in new, SQL-like (but not SQL) general query APIs (GraphQL, etc.) are actually already fairly completely addressed in modern relational databases, which are designed for multiuser access with users having different permissions. So exposing the datastore directly solves, rather than causes, the issues it raises with common generalized near-SQL query APIs.
- carsongross 10y ago
  Yeah, no. You can't expose generalized query functionality without either encoding the security constraints in the datastore query layer (which is really, really hard, we are talking column-level security constraints and worse) or limiting the expressiveness of your query layer. That's the trade off and, in most real world systems, the data stores are wide open to the developer because expressivity wins. Yes, the technology is there to secure databases at the row level, for example, but people don't use it. They just use a user/pass with total access. A lot of folks are tossing HTTP endpoints on data stores without thinking through the security/expressiveness tradeoff.
  - dragonwriter 10y ago
    > You can't expose generalized query functionality without either encoding the security constraints in the datastore query layer (which is really, really hard, we are talking column-level security constraints and worse) or limiting the expressiveness of your query layer. Column and even row-level security constraints are not "really, really hard" to use in modern DBs, and you have to do the analysis of what people should be able to access and effect on that level to build the app, no matter whether you are implementing the constraints through a separate application layer or through the DB itself.
    - carsongross 10y ago
      A user can only see the salaries of all his direct reports. Again, there's a reason why almost every web app built in the last twenty years just used user/pass credentials and didn't implement db security beyond that: expressiveness. But I'm not gonna change your mind on it today. Just think about it for a while.
      - dragonwriter 10y ago
        > A user can only see the salaries of all his direct reports. With an employee-salary table, that's a fairly simple row-level security rule. > Again, there's a reason why almost every web app built in the last twenty years just used user/pass credentials and didn't implement db security beyond that: expressiveness. I agree that there is a reason, but that's not it; there is a combination of the lack of features in popular (particularly free) databases in the early part of the period (heck, MySQL/MariaDB still doesn't support row-level security), inertia, and lack of database knowledge among web app developers. > But I'm not gonna change your mind on it today. Just think about it for a while. This is not a new issue for me; I have been thinking about it for quite a long while.

dragonwriter 10y ago

> Look, kids. You are going to have to have an execution layer you can trust somewhere, you can't just expose your data store directly to the outside world or you run into an infinite number of security issues The security issues your source points to in new, SQL-like (but not SQL) general query APIs (GraphQL, etc.) are actually already fairly completely addressed in modern relational databases, which are designed for multiuser access with users having different permissions. So exposing the datastore directly solves, rather than causes, the issues it raises with common generalized near-SQL query APIs.

carsongross 10y ago
Yeah, no. You can't expose generalized query functionality without either encoding the security constraints in the datastore query layer (which is really, really hard, we are talking column-level security constraints and worse) or limiting the expressiveness of your query layer. That's the trade off and, in most real world systems, the data stores are wide open to the developer because expressivity wins. Yes, the technology is there to secure databases at the row level, for example, but people don't use it. They just use a user/pass with total access. A lot of folks are tossing HTTP endpoints on data stores without thinking through the security/expressiveness tradeoff.
- dragonwriter 10y ago
  > You can't expose generalized query functionality without either encoding the security constraints in the datastore query layer (which is really, really hard, we are talking column-level security constraints and worse) or limiting the expressiveness of your query layer. Column and even row-level security constraints are not "really, really hard" to use in modern DBs, and you have to do the analysis of what people should be able to access and effect on that level to build the app, no matter whether you are implementing the constraints through a separate application layer or through the DB itself.
  - carsongross 10y ago
    A user can only see the salaries of all his direct reports. Again, there's a reason why almost every web app built in the last twenty years just used user/pass credentials and didn't implement db security beyond that: expressiveness. But I'm not gonna change your mind on it today. Just think about it for a while.
    - dragonwriter 10y ago
      > A user can only see the salaries of all his direct reports. With an employee-salary table, that's a fairly simple row-level security rule. > Again, there's a reason why almost every web app built in the last twenty years just used user/pass credentials and didn't implement db security beyond that: expressiveness. I agree that there is a reason, but that's not it; there is a combination of the lack of features in popular (particularly free) databases in the early part of the period (heck, MySQL/MariaDB still doesn't support row-level security), inertia, and lack of database knowledge among web app developers. > But I'm not gonna change your mind on it today. Just think about it for a while. This is not a new issue for me; I have been thinking about it for quite a long while.