3 ms·
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
by 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. ¯\_(ツ)_/¯