On Friday 18 July 2003 00:51, russm wrote: > On Friday, July 18, 2003, at 07:27 AM, Gustaf Neumann wrote: > > On Thursday 17 July 2003 04:23, you wrote: > >> You always want more choice and flexibility, not less ... > > > > i always wanted to make my life less complicated, not more. > > but as I pointed out before, changing the applications concept of "the > far end" to give you the semantics you want will reduce the usefulness > of that function for other users - you're throwing out information (the > actual endpoint of the TCP connection) and replacing it with something > that is already knowable, is less trustworthy, is less well defined, > and is less useful for servers that are not behind a reverse proxy.
i think, we all agree, that per default, the setting "running behind reverse proxy" is for many good reasons turned off, and we are talking about the situation, what should happen, when it is turned on. well, redefining the semantics of ns_conn peeraddr does not necessarily imply that the information is thrown away completely. i would certainly like to have this info around, for some - i would expect rare - situations, but maybe under a different name, such as [ns_conn tcp_peeraddr] (which will point always to the "physical other end" of the actual tcp connection) > by all means, have the option to sniff X-Forwared-For as a configurable > parameter, but the default behaviour should not be to throw away > information that the application may want to know... > > here's a simple example of why you'd want to know and log the actual > endpoint - you're running a server, not behind a reverse proxy, unless i understood the example wrong, it is not a good one: when you are running the aolserver not behind a proxy, the switch "running behind a rreverse proxy" should not be turned on. all the best -gustaf > that is > having it's passwords brute-forced over the network... a single user > runs a script to try name/password pairs out of a dictionary, and sends > a randomised X-Forwarded-For header with every one... you see many > failed logins from many IP addresses, but have to resort to > snoop/netstat to find the actual address of the miscreant... If > [ns_conn peeraddr] and the access-log behave as they should, you see > many failed logins from a single IP, which you can then easily filter > out with [ns_conn peeraddr]... > > > russell muetzelfeldt <[EMAIL PROTECTED]> > > "Never offend people with style when you can offend them with > substance." > --Sam Brown -- Univ.Prof. Dr.Gustaf Neumann Abteilung f�r Wirtschaftsinformatik WU-Wien, Augasse 2-6, 1090 Wien -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
