The user’s definition should be in charge of the application itself, since it is it who controls the actions in the database. Unless the database had registered each user and the connection used the respective credentials.
In general, I would recommend auditing the application as it is more flexible than directly in the database.
However, I know that putting an audit in the bank also has its advantages there, for example in the case of changes via script or coming from other systems.
And precisely because of situations like these it is difficult to rely on a parameter defined by the application. This coupling can cause problems for bank changes that do not come through the application.
Without considering a deeper change, we can think of some ways around this situation.
But first, we must understand that the connections in a web application usually stay in a pool and are reused in several requests, possibly by different users.
Setting the user whenever accessing the database
One way around the situation is by setting the user in the database at the beginning of each method that will access the database.
To facilitate this you could use Aspect Guidance with Spring AOP to intercept all Daos methods, for example, so that the command runs automatically.
Another possibility of applying AOP would be to create an annotation @Auditoria
. So whenever a method with this annotation was executed, the user would be passed to the database.
Encapsulate the connection
Another alternative would be to create a bean encapsulating the connection, which would execute the command defining the user whenever it was used.
The scope of this bean would have to be request, to be recreated with each request. It would then recover a connection and set the user.
The bean could implement the methods of Connection
to facilitate integration.
Filter with connection reuse
A third approach would be to put a request filter in the application.
With each request it opens a connection and updates the user name.
This connection would have to be stored during the entire request and used by all methods accessing the database.
Considerations
Anyway, I tried to come up with some ideas. In fact it would be necessary to ascertain precisely how the system works not to end with gambiarras, but I hope to have helped you to think of a possible solution.
Como eu posso criar histórico sem ter que ficar a cargo da aplicação de fazer isto?
Giving permission to each user in the database, because the only user the bank sees is the one connected to it. I don’t think it’s a good way to do this.– Oralista de Sistemas
@Renan The Problem is who manages the connections is the Spring and when it comes to creating the Datasource There is no way I keep switching the connection user. Imagine that if I log in as Vander I will have set the connection user as such. Another person logs into the system as alex will set the connection user as alex? Since it may even be the same connection, because from what I’m observing the Spring does not generate a new connection to each request made but manages the ones it has and creates and closes connections when necessary.
– Vander