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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
