4 ms·

Having implemented it, I don’t really agree. It adds a layer of security and auditability at the database level; logging works even if someone logs into the dat

Having implemented it, I don’t really agree. It adds a layer of security and auditability at the database level; logging works even if someone logs into the database from a cli and modifies it directly; and you can implement roles in such a way that prevent changes to the audit logs. None of this is possible at the application level. To me this is one of those things that looks hard until you look deeply. Yes, it does take more time to do things right. But not that much more. Honestly, if your application is bound to a database but you’re not a database expert, it’s a gap you should probably consider filling. So much effort is put into making the application layer do things that the database layer can already do, but the database is generally much more efficient and correct.

pdimitar 3y ago
> To me this is one of those things that looks hard until you look deeply. Yes, it does take more time to do things right. But not that much more. Nope, it's much, MUCH more. Application frameworks are not made to switch DB users, they expect a singular DB config with which they work. Can it be changed? Sure. Will any stakeholder pay for it? Nope.
- doctor_eval 3y ago
  You’re really overstating your case. There is nothing intrinsic to frameworks that makes this difficult. It’s basically a few lines of SQL code emitted as part of database transaction setup. The frameworks I’ve used have had the ability to register a transaction initialiser during pool setup. Other than that the framework doesn’t even have to know about it. Most of the “complexity” is on the database side, but it’s really not that hard. “Will any stakeholder pay for it?”. If your stakeholders are serious about application security, then I would expect so. (I’ll just add that I know of at least one product that does this - Postgraphile sets the database role up front for requests from the web. I seem to recall that Supabase does something similar.)
  - pdimitar 3y ago
    > “Will any stakeholder pay for it?”. If your stakeholders are serious about application security, then I would expect so. I want to live in your world where they apparently care. In mine they never did. 20+ years career. > You’re really overstating your case. There is nothing intrinsic to frameworks that makes this difficult. You could be right that I am overstating it, though you also shouldn't underestimate the "blessed" ways that web frameworks do stuff. In practically all that I worked on they just wanted you to chuck either a database URL or break it apart on host/port/user/pass/db-name and didn't make any effort to dynamically create / drop users as the application is creating and deleting them. > The frameworks I’ve used have had the ability to register a transaction initialiser during pool setup. As said above, I know it's doable. What I am saying is that nobody ever gave me the time to do it and with time I stopped caring. Turned out that putting the currently logged in users in global logger and telemetry contexts is good enough. ¯\_(ツ)_/¯

pdimitar 3y ago

> To me this is one of those things that looks hard until you look deeply. Yes, it does take more time to do things right. But not that much more. Nope, it's much, MUCH more. Application frameworks are not made to switch DB users, they expect a singular DB config with which they work. Can it be changed? Sure. Will any stakeholder pay for it? Nope.

doctor_eval 3y ago
You’re really overstating your case. There is nothing intrinsic to frameworks that makes this difficult. It’s basically a few lines of SQL code emitted as part of database transaction setup. The frameworks I’ve used have had the ability to register a transaction initialiser during pool setup. Other than that the framework doesn’t even have to know about it. Most of the “complexity” is on the database side, but it’s really not that hard. “Will any stakeholder pay for it?”. If your stakeholders are serious about application security, then I would expect so. (I’ll just add that I know of at least one product that does this - Postgraphile sets the database role up front for requests from the web. I seem to recall that Supabase does something similar.)
- pdimitar 3y ago
  > “Will any stakeholder pay for it?”. If your stakeholders are serious about application security, then I would expect so. I want to live in your world where they apparently care. In mine they never did. 20+ years career. > You’re really overstating your case. There is nothing intrinsic to frameworks that makes this difficult. You could be right that I am overstating it, though you also shouldn't underestimate the "blessed" ways that web frameworks do stuff. In practically all that I worked on they just wanted you to chuck either a database URL or break it apart on host/port/user/pass/db-name and didn't make any effort to dynamically create / drop users as the application is creating and deleting them. > The frameworks I’ve used have had the ability to register a transaction initialiser during pool setup. As said above, I know it's doable. What I am saying is that nobody ever gave me the time to do it and with time I stopped caring. Turned out that putting the currently logged in users in global logger and telemetry contexts is good enough. ¯\_(ツ)_/¯