Hi,
At $work I am often entertained by log entries like:
invalid input syntax for integer: "21' && 1=2)) Uni/**/ON
SEl/**/eCT 0x646665743166657274,0x646665743266657274,
0x646665743366657274 -- "
They're entertaining mostly because I know our web guy has heard
of SQL injection and doesn't write stuff where it would work. So
I'm mostly just entertained to see what wacky tactics the lowlifes
come up with.
But suppose I wanted to log more information about the origins
of the attempts. As is often the case with web apps, %r/%h/%u
won't give me anything useful, because %h will always be our
own server hosting the app, and %u is the hardcoded name the app
uses to connect. Obviously, each app itself would need to be tweaked
to pass along what I really care about, the actual remote host and
the user identity within the app.
That could be done today by having the app construct some 64-
character string out of the app name, remote IP, and identity,
and setting that as application_name, and I could log %a.
I just wonder if anybody thinks web apps, and therefore this
scenario, are common enough these days to maybe justify one
or two more GUCs with their own log_line_prefix escapes, such
as app_client_addr or app_user. Naturally they would only be
as reliable as the app setting them, and uninterpreted by
PostgreSQL itself, and so functionally no different from the
uninterpreted string already available as application_name.
The benefit is perhaps to be clearer than just overloading
application_name to carry two or three pieces of information
(and perhaps privacy, if you care about app user identities and
source IPs showing up in ps titles).
Worth considering, or is application_name Good Enough?
-Chap
