Current situation
Currently, our DB setup gives permissions on the event_log table to PUBLIC (i.e. every DB user).
The purpose of this is to allow running only the migrations using a higher-privileged user, and have application connect with a lower-privileged one.
But it seems like granting this to public goes a bit further than needed – now even the monitoring robot user can insert into the eventlog table (or, after #177, also delete from there).
Ideal situation
Ideally we would only grant the access to the application user (and maybe to human users with administration privileges).
Implementation notes
The problem here is that the flyway script is static (part of our jar file), and the user name might be different for every application where this is running. We might need flyway placeholders, or java-based migrations for setting this up.
Current situation Currently, our DB setup gives permissions on the event_log table to PUBLIC (i.e. every DB user).
The purpose of this is to allow running only the migrations using a higher-privileged user, and have application connect with a lower-privileged one. But it seems like granting this to public goes a bit further than needed – now even the monitoring robot user can insert into the eventlog table (or, after #177, also delete from there).
Ideal situation
Ideally we would only grant the access to the application user (and maybe to human users with administration privileges).
Implementation notes
The problem here is that the flyway script is static (part of our jar file), and the user name might be different for every application where this is running. We might need flyway placeholders, or java-based migrations for setting this up.