Hacker News Reader

Comment by SideburnsOfDoom | Hacker News Reader

> If you give client code access to your database you have to trust that client to respect ...

I get all that but I still am unsure of what you mean. A database is useless if no-one can ever access it. So some code somewhere accesses that database, not so? And other code makes request to this code?

What do you consider "client code" and what are you comparing this to? Why do you think that lambda functions cannot be in the second category, and if they cannot be, why can't they use the same gated mechanisms as other "client code", and I would assume that they use restful http to read, and http or message queues to write?

> There's risk of denial of service

in the AWS lambda case, the rate limiting is specifically the role of the api gateway. There's always the risk, and I don't think that lambda increases it.

View on HN

First, "client". A client is anything that calls a server but is outside the trust boundary of that server.

And yes, of course there's code that accesses the database. The problem is that if it's client code, that code must be trusted by the database.

A better approach is where there's code between the client and the database, also on the server (server estate, at least), that verifies data going into and out of the database.

That isolates client-side changes - malicious, unintentional or otherwise, that might impact the data, because there's a server-side gatekeeper.

So all of a sudden FAAS is more appealing than BAAS, and the FAAS API gateway doesn't just do routing, it does validation too. Guess what, you just created an application/business logic layer on a middle tier, and it's no longer serverless.

"...Why do you think that lambda functions cannot be in the second category..."

They can indeed be in the second category. The author, however, specifically calls out direct database access from the client without lambda functions.

Why would a lambda fn be considered untrusted client code?

If the database and the lamdba fn are both in AWS, then they're on the same "server estate". How is this any different from the server portion a web app?

Maybe I wasn't clear on that - a lambda function calling the database is indeed trusted.

API Gateway in AWS can't directly talk to the DB. It has to either hit a mock (where a canned response is sent back), a lambda function, or serve as an HTTP proxy. You may of course be referring to the more abstract concept of an API Gateway that then talks to a backend DB directly without passing through intervening code, and yes, that would be stupid. But you hardly need serverless infrastructure to achieve that level of wrongness; even with a server in between, you can easily achieve the equivalent of that by taking a SQL string from the client verbatim and executing it against your DB.

This is something that annoys me about relative terms like "client" and "backend". An entity can simultaneously be the client of one pair and the server of another.

No good solution comes to mind, aside from being very explicit. "database client" vs "user client".

Indeed, this was a very confusing conversation because of it.

If by client you mean "a web browser" then "a better approach is where there's code between the client and the database" makes perfect sense; but in the meaning of "client" where any code that calls the database is a client of the database, it's balderdash.

I honestly don't think that a "trust boundary" has anything to do with it, generally.

> The author, however, specifically calls out direct database access from the client without lambda functions.

Ah sorry, I missed this part:

> 2 Using another example of BaaS, we’ve allowed the client direct access to a subset of our database (for product listings)

"The client" in this sense is a web browser and is thus completely untrustworthy. He seems to be talking about read access, hopefully with an api gateway for auth and rate limiting in front of it. But yes, it is wise to be much more wary of this case.

> I get all that but I still am unsure of what you mean.

Direct database access would be like exposing ODBC from the DB directly to a web application. You either have to trust that the application doesn't do a "drop table ..." or hope that the DB has fine-grained enough access controls to prevent that.

Whereas in a SOA design, the API endpoint runs your code that gates access to the DB.

"web application" could mean a number of things. To me "web app" in the comments above meant the code on a server that handles http requests, not the browser client of it. You are talking about Javascript running in the browser of a random internet user, right? It could be catastrophic to allow that level of access to a database from the public web, obviously.

As is pointed out in (1) that can happen already through carelessness. And it does (2)

But it probably isn't what was intended in a newly designed general system. That would assume great stupidity.

I suspect that even the "no code, just access the database" actually has some kind of code and config in front of the db, like odata (3). I'm not saying that odata is great, but it is an example of trivial access to a database. it's gated, mostly read-only and configurable, but it probably doesn't count as "writing a custom server app to gate to a database"

1) https://news.ycombinator.com/item?id=11925043

2) https://www.owasp.org/index.php/Top_10_2013-A1-Injection

3) http://www.odata.org/

Reply on news.ycombinator.com