I assume it's the application running on Tomcat that is communicating with the database? In that case it makes sense that your database activity log states the incoming connection as localhost, because that's exactly where it is coming from. Your Tomcat logs will record the incoming external IP address, so why do you want that information duplicated in your database logs? It would not be normal, and in my opinion no way desired, to 'spoof' the client IP of the incoming database connections.
I just want that database create logs of SELECT, DELETE, UPDATES (changes in tables) with IP Address of remote user. Normally i could program this in my application but it would be much easier and faster using database.
posted 2 years ago
Just want use for example database triggers to create logs of my application. But the problem is that i need some kind of identification (IP or user that make changes in database via application).
From yours answers i see that i will need do it my app.
The SQL Slammer exploit that compromised many ATM (cashpoint) machines worked precisely because there was direct Internet access to the Microsoft SQL Server database. You should never give the Internet direct access to a database server.
If you write a web application in Java and do your database functions through that, you limit the amount of damage an intruder can do - at least if the app is well-written. The Tomcat server and database server don't have to be on the same machine, but the database server should not be visible on the general Internet, only on your local LAN.
"privilege" comes from the Latin words for "private" and "law" (legal) and dates to feudal times. To "claim privilege" meant that you were above the laws that applied to the common people.
I can understand how it would be useful to have log information on who caused the action that resulted in a db call and I've worked with an application that logs just that kind of info.
As has been mentioned before, your Servlet application has the means to obtain the incoming IP address, and of course the currently logged in user (if you have registered users), so the solution we implemented was to have the DAO code log out the details of the request it was about to make to the database. Something like: