On Sunday 20 July 2003 03:31, you wrote:
On 2003.07.20, Gustaf Neumann [EMAIL PROTECTED] wrote:
my primary point is: if you are running an aolserver behind a proxy,
the current value of [ns_conn peeraddr] is not very useful.
So:
proc ns_clientaddr {} {
set addr [lindex [ns_set iget
+-- On Jul 21, Gustaf Neumann said:
If the community prefers to keep [ns_conn peeraddr] as it is, we would
would not alter these 70+ occurances, but modify our local copy
of [ad_conn ...]
So it sounds like you don't even HAVE the problem you're complaining
about! It would be nice
On Sunday, July 20, 2003, at 11:31 AM, Dossy wrote:
I'm still unsure what benefit there is in changing the current
semantics
of [ns_conn peeraddr] ...
Because then people with an extensive codebase don't have to go and
change it all to get the new functionality, they just have to flip the
switch
On 2003.07.21, Matthew Walker [EMAIL PROTECTED] wrote:
On Sunday, July 20, 2003, at 11:31 AM, Dossy wrote:
I'm still unsure what benefit there is in changing the current
semantics of [ns_conn peeraddr] ...
Because then people with an extensive codebase don't have to go and
change it all to
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
On Saturday 19 July 2003 06:32, you wrote:
i wonder that this discussion was not coming up earlier...
Probably because using IP address in most cases is a bad idea and there
are probably better ways of tracking people (such as unique persistent
cookies).
using the IP address as a means to
Actually I think Dossy is proposing to add a new arg to the ns_conn
command, and not changing the current behavior of ns_conn peeraddr in
order to keep backwards compatibility. I believe the proposal was to add
something like ns_conn clientaddr. Dossy, please correct me if I'm wrong.
Gustaf
On 2003.07.19, Gustaf Neumann [EMAIL PROTECTED] wrote:
using the IP address as a means to track people is certainly a bad
idea. a common usage in OpenACS is for documentation purposes.
E.g. when an entry is created in the content repository it is logged, who
(ad_conn user_id) created it at
+-- On Jul 19, Dossy said:
Why even record their IP address if you have their user ID?
When someone hacks your system and costs your thousands of dollars, the
FBI might find the IP address useful in tracking down the hacker.
--
AOLserver - http://www.aolserver.com/
To Remove yourself
+-- On Jul 19, Dossy said:
Configuring an optional whitelist of peeraddrs to trust would be neat
(only look for the X-Forwarded-For header if the peeraddr belongs to a
list of IPs).
My dqd_log module has an AccelAddresses parameter. If [ns_conn
peeraddr] is in the AccelAddresses list,
On 2003.07.19, Rob Mayoff [EMAIL PROTECTED] wrote:
+-- On Jul 19, Dossy said:
Why even record their IP address if you have their user ID?
When someone hacks your system and costs your thousands of dollars, the
FBI might find the IP address useful in tracking down the hacker.
If
+-- On Jul 19, Dossy said:
If someone's going to hack your system, presumably they're not going to
be dumb enough to do it from their OWN IP address. (That's like making
threatening phone calls from your home landline phone! Duh!)
Presumably the FBI will want to investigate the
FWIW, I hate having a bunch of separate TCL routines to do related
things. IMO, one of the nice things about TCL is that knowing you
want to do a file thing makes it reasonable to look at [file] first,
not [openfile], [rewindfile], [truncatefile], ... Separate routines
makes it harder to find
+-- On Jul 19, Jim Wilcoxson said:
Separate routines makes it harder to find out how do I do this
thing?,
That sounds more like a problem of inadequate documentation.
Overloading ns_conn is easy in TCL:
It's not as easy as NOT overloading it, and it slows down every
invocation of
On Saturday 19 July 2003 18:30, you wrote:
Nate, while you and I were talking, Gustaf actually suggested exactly
the same thing to the mailing list in an previous email.
At this point, does anyone see a problem with ns_conn clientaddr?
Obviously, forgery of the X-Forwarded-For header is going
On 2003.07.20, Gustaf Neumann [EMAIL PROTECTED] wrote:
my primary point is: if you are running an aolserver behind a proxy,
the current value of [ns_conn peeraddr] is not very useful.
So:
proc ns_clientaddr {} {
set addr [lindex [ns_set iget [ns_conn headers] x-forwarded-for] end]
if
On 2003.07.17, Gustaf Neumann [EMAIL PROTECTED] wrote:
it is fine for me to keep [ns_conn peeraddr] as it is, but
it leads to a scenario, where we (at our site) have to
introduce a [ns_conn clientaddr] (or [ad_conn clientaddr])
or to ignore the fact, that ns_conn peeraddr does not
return
I like this solution the best so far. Also nice in that it keeps things
simple. Simple is good!
Dossy wrote:
My vote is that [ns_conn peeraddr] always return the address of the
remote end of the actual socket connection. If I suspect that peeraddr
may be a reverse proxy, I want the choice
On Wednesday 16 July 2003 03:27, you wrote:
On Wednesday, July 16, 2003, at 10:36 AM, Gustaf Neumann wrote:
PS: with the log-file-change in the aolserver, there is a
potential small security leak. The proxy MUST bock
requests that have already X-Forwarded-For set (easily
configurable
On Saturday 12 July 2003 14:30, you wrote:
On Saturday 12 July 2003 14:13, you wrote:
That X-Forwarded-For is a very useful little feature, thanks for doing
it Zoran!
Well, it seemed trivial to include, so I did it.
Some people have expressed concern about potential
security issue with
On Wednesday, July 16, 2003, at 10:36 AM, Gustaf Neumann wrote:
PS: with the log-file-change in the aolserver, there is a
potential small security leak. The proxy MUST bock
requests that have already X-Forwarded-For set (easily
configurable in pound). otherwise, it is possible that the
wrong
That X-Forwarded-For is a very useful little feature, thanks for doing
it Zoran!
But FYI, Gustaf Neumann's original comment mentioned using Pound with
OpenACS, and several users have reported that Pound has problems
there. I've never used Pound myself, but specifically, they say Pound
doesn't
Andrew Piskorski wrote:
OpenACS does have a few
pages using ns_write by default, and for the occasional page where it
makes sense, being able to use ns_write is certainly very useful and
important.
It probably wouldn't be too hard to change these to not use ns_write, I
think most applications
This would make the most sense to me. Ops loves to be able to tweak
these sorts of things. ;-) Thanks again for adding it!
Zoran Vasiljevic wrote:
Well, it seemed trivial to include, so I did it.
Some people have expressed concern about potential
security issue with this, so I may end up
On 2003.07.12, Zoran Vasiljevic [EMAIL PROTECTED] wrote:
Well, it seemed trivial to include, so I did it.
Some people have expressed concern about potential
security issue with this, so I may end up making this
configurable over some (yet to name) ns_param in the
config file for the nslog
25 matches
Mail list logo
