[23841] in Perl-Users-Digest
Perl-Users Digest, Issue: 6044 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jan 29 22:26:48 2004
Date: Thu, 29 Jan 2004 19:21:16 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 29 Jan 2004 Volume: 10 Number: 6044
Today's topics:
return code to STDOUT (MischMan)
Re: return code to STDOUT (Walter Roberson)
Re: return code to STDOUT <jurgenex@hotmail.com>
Re: return code to STDOUT <robin@csf.edu>
Re: return code to STDOUT <matthew.garrish@sympatico.ca>
Re: return code to STDOUT <matthew.garrish@sympatico.ca>
Re: return code to STDOUT <robin@csf.edu>
Re: Run speed question <tassilo.parseval@rwth-aachen.de>
Re: Run speed question <edgrsprj@ix.netcom.com>
Re: Run speed question <robin@csf.edu>
Re: Run speed question <matthew.garrish@sympatico.ca>
Re: Run speed question <spamtrap@dot-app.org>
Running a daemon as root (Norman ELton)
Re: Running a daemon as root <troc@pobox.com>
Re: Running a daemon as root (Norman ELton)
Re: Running Another Application (Naveen Reddy)
Re: Running Perl script on Windows NT <tadmc@augustmail.com>
Re: Script that blocks certain IP's <gnari@simnet.is>
Re: Script that blocks certain IP's <flavell@ph.gla.ac.uk>
Re: Script that blocks certain IP's <gnari@simnet.is>
Re: Script that blocks certain IP's (Dino)
Re: Script that blocks certain IP's (Dino)
Re: Script that blocks certain IP's <kuujinbo@hotmail.com>
Re: Script that blocks certain IP's <flavell@ph.gla.ac.uk>
Re: Script that blocks certain IP's <ceo@nospan.on.net>
Re: Script that blocks certain IP's <pkent77tea@yahoo.com.tea>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 22 Jan 2004 20:03:37 -0800
From: p_misch@hotmail.com (MischMan)
Subject: return code to STDOUT
Message-Id: <e8e398c4.0401222003.68d7b2c2@posting.google.com>
newbie perl question: looking for a simple accurate way to state to
STDOUT that the program ran OK ...
thanx :)
------------------------------
Date: 23 Jan 2004 04:14:10 GMT
From: roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson)
Subject: Re: return code to STDOUT
Message-Id: <buq72i$cfg$1@canopus.cc.umanitoba.ca>
In article <e8e398c4.0401222003.68d7b2c2@posting.google.com>,
MischMan <p_misch@hotmail.com> wrote:
:newbie perl question: looking for a simple accurate way to state to
:STDOUT that the program ran OK ...
And if the program might have bugs that you don't know about, then how
would you know that the program -really- ran correctly rather than
just running according to the way you programmed it?
But I suspect that isn't what you wanted to hear. What you
probably wanted to hear was:
print "OK\n";
which could be improved to
print STDOUT "OK\n";
just in case select() has been used to change the default location
to print to.
--
History is a pile of debris -- Laurie Anderson
------------------------------
Date: Fri, 23 Jan 2004 04:15:00 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: return code to STDOUT
Message-Id: <8d1Qb.14481$h77.7187@nwrddc02.gnilink.net>
MischMan wrote:
> newbie perl question: looking for a simple accurate way to state to
> STDOUT that the program ran OK ...
What about
print STDOUT "the program ran OK ...";
jue
------------------------------
Date: Thu, 22 Jan 2004 21:30:52 -0700
From: "Robin" <robin@csf.edu>
Subject: Re: return code to STDOUT
Message-Id: <buq8vk$vj7$1@reader2.nmix.net>
>newbie perl question: looking for a simple accurate way to state to
>STDOUT that the program ran OK ...
>thanx :)
just print something with print "something"; I know this has already been
answered, I wonder why I'm even here. You can also code:
select (STDOUT);
print "Something";
This will select your default file handle, STDOUT and then print it, if
you've selected another file.
peace,
-Robin
------------------------------
Date: Fri, 23 Jan 2004 17:30:27 -0500
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: return code to STDOUT
Message-Id: <5ghQb.20096$U77.1727535@news20.bellglobal.com>
"Robin" <robin@csf.edu> wrote in message
news:buq8vk$vj7$1@reader2.nmix.net...
> >newbie perl question: looking for a simple accurate way to state to
> >STDOUT that the program ran OK ...
>
> >thanx :)
>
> just print something with print "something"; I know this has already been
> answered, I wonder why I'm even here. You can also code:
>
> select (STDOUT);
> print "Something";
>
>
> This will select your default file handle, STDOUT and then print it, if
> you've selected another file.
Did you just read Jurgen's post and thought you understood it? print will
*always* print to STDOUT by default, unless you specifically send the data
to another filehandle or output stream. The only reason to re-select STDOUT
is if you've already used a select statement in your code, and even then
it's incredibly pointless in this case to select STDOUT just to print an
okay message at the end of the script, don't you think? (Oh, sorry. I forgot
you don't...)
Matt
------------------------------
Date: Fri, 23 Jan 2004 17:33:40 -0500
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: return code to STDOUT
Message-Id: <5jhQb.20097$U77.1728829@news20.bellglobal.com>
"Matt Garrish" <matthew.garrish@sympatico.ca> wrote in message
news:5ghQb.20096$U77.1727535@news20.bellglobal.com...
>
> Did you just read Jurgen's post and thought you understood it?
>
The question still stands, but I meant to say Walter's post...
Matt
------------------------------
Date: Fri, 23 Jan 2004 18:13:01 -0700
From: "Robin" <robin@csf.edu>
Subject: Re: return code to STDOUT
Message-Id: <bushoq$1hm$1@reader2.nmix.net>
"Matt Garrish" <matthew.garrish@sympatico.ca> wrote in message
news:5ghQb.20096$U77.1727535@news20.bellglobal.com...
>
> "Robin" <robin@csf.edu> wrote in message
> news:buq8vk$vj7$1@reader2.nmix.net...
> > >newbie perl question: looking for a simple accurate way to state to
> > >STDOUT that the program ran OK ...
> >
> > >thanx :)
> >
> > just print something with print "something"; I know this has already
been
> > answered, I wonder why I'm even here. You can also code:
> >
> > select (STDOUT);
> > print "Something";
> >
> >
> > This will select your default file handle, STDOUT and then print it, if
> > you've selected another file.
>
> Did you just read Jurgen's post and thought you understood it? print will
> *always* print to STDOUT by default, unless you specifically send the data
> to another filehandle or output stream. The only reason to re-select
STDOUT
> is if you've already used a select statement in your code, and even then
> it's incredibly pointless in this case to select STDOUT just to print an
> okay message at the end of the script, don't you think? (Oh, sorry. I
forgot
> you don't...)
did read the post...actually, that's kinda what I meant...
-Peace-Robin
------------------------------
Date: 19 Jan 2004 22:04:55 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: Run speed question
Message-Id: <buhka7$d24$1@nets3.rz.RWTH-Aachen.DE>
Also sprach edgrsprj:
> Well, that was easy. Thanks. They have a free downloadable Perl operating
> system. I have not tried to download it yet but will probably check on that
> later today. So, people anywhere could help develop Perl programs. That
> was an important part of what I was looking for.
>
> Question: Can anyone volunteer an opinion regarding how fast Perl programs
> perform operations such as simple calculations, comparing two strings, data
> sorts etc. compared some compiled program such as one written in Fortran? I
> want to make certain that we don't have people writing slow running programs
> such as with Basic interpreter programs where a single line of code is
> examined and run at a time.
Perl is a mixture between an interpreted and compiled language. In its
character it is more interpreted, however it does have some of the
advantages of compiled languages (such as some fatal error reporting at
compile- and not runtime).
As for Fortran: Of all those higher level languages, Fortran might
easily be the most performant of all, even leaving behind C in some
areas. Also remember your initial list of requirements. Fortran doesn't
meet a lot of those requirements.
But when you compare Perl to languages similar in concept Perl's
performance in general is very convincing. For those things you mention
(in essence: data munging and system-interaction) it is almost ideal.
When you do string-process for instance, you can always write a faster
program in C or in Fortran. However, a Perl program could be faster than
a simple-minded C program doing the same thing reliably (especially when
things like I/O are involved).
And I wouldn't worry about Basic. It's not really a challenge for Perl
to beat Basic in probably every aspect performance-wise.
> Question: Can anyone volunteer an opinion regarding how well that
> downloadable Perl operating system runs on Windows XP versus Windows 98 and
> Unix systems?
In my experience, the differences are negligible or even less. Perl has
UNIXoid roots for sure, but over the years a lot of Win32 specific code
has assembled in the Perl source tree. I only used it once on XP and
there was no noticeable difference to 98/ME either.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Mon, 19 Jan 2004 22:53:41 GMT
From: "edgrsprj" <edgrsprj@ix.netcom.com>
Subject: Re: Run speed question
Message-Id: <VdZOb.15646$i4.8977@newsread1.news.atl.earthlink.net>
January 19, 2004
I got the impression that Perl had that type of mixed character. I am going
to start downloading that operating version and see how well it performs. I
expect that the speed should be more than adequate for initial program
development purposes. If all of this works then people can always translate
any modules into a faster language if that becomes necessary.
I was not planning to use Fortran and wanted to avoid using Basic if
possible. Perl appears to be an almost universal language for Web site CGI
usage. So that makes it quite attractive.
"Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de> wrote in message
news:buhka7$d24$1@nets3.rz.RWTH-Aachen.DE...
> Also sprach edgrsprj:
>
> Perl is a mixture between an interpreted and compiled language. In its
> character it is more interpreted, however it does have some of the
> advantages of compiled languages (such as some fatal error reporting at
> compile- and not runtime).
>
> As for Fortran: Of all those higher level languages, Fortran might
> easily be the most performant of all, even leaving behind C in some
> areas. Also remember your initial list of requirements. Fortran doesn't
> meet a lot of those requirements.
>
------------------------------
Date: Mon, 19 Jan 2004 17:24:15 -0700
From: "Robin" <robin@csf.edu>
Subject: Re: Run speed question
Message-Id: <buhtcb$mfe$1@reader2.nmix.net>
> Well, that was easy. Thanks. They have a free downloadable Perl
operating
> system. I have not tried to download it yet but will probably check on
that
> later today.
I'd be careful with that...peace-robin
------------------------------
Date: Mon, 19 Jan 2004 20:42:39 -0500
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: Run speed question
Message-Id: <cI%Ob.4939$rW5.216099@news20.bellglobal.com>
"Robin" <robin@csf.edu> wrote in message
news:buhtcb$mfe$1@reader2.nmix.net...
>
> I'd be careful with that...peace-robin
>
Please stop giving bad advice. What possible reason do you have for warning
against using ActiveState's Perl distribution?
Matt
------------------------------
Date: Tue, 20 Jan 2004 02:55:23 GMT
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: Run speed question
Message-Id: <pan.2004.01.20.02.55.23.371007@dot-app.org>
On Mon, 19 Jan 2004 20:42:39 -0500, Matt Garrish wrote:
> What possible reason do you have for warning
> against using ActiveState's Perl distribution?
It runs on Windows... ;-)
sherm--
------------------------------
Date: 22 Jan 2004 08:39:25 -0800
From: elnormo@hotmail.com (Norman ELton)
Subject: Running a daemon as root
Message-Id: <a67295c3.0401220839.2f5d36d8@posting.google.com>
Hello,
I am getting started on a project where a central server communicates
with nodes across a network. The central server will be written in
PHP, since most of it will be accessible over the web. The nodes are
not accessible to the end user, so I don't really care what they're
written in, but unfortunately, they need to be able to execute
programs as root.
I figured perl would be a good tool for the nodes, since it's
available on most linux boxes. I realize that running a root daemon is
risky business. What are good strategies to prevent the nodes from
being... misused? For instance, what's a good way to authenticate the
server and the node?
I searched for strategies relating to perl running as root, but didn't
come up with anything conclusive, other than the obvious, don't trust
ANY input. Validate everything.
Any other ideas?
Thanks,
Norman
------------------------------
Date: Thu, 22 Jan 2004 17:06:54 GMT
From: Rocco Caputo <troc@pobox.com>
Subject: Re: Running a daemon as root
Message-Id: <slrnc100s3.eu.troc@eyrie.homenet>
On 22 Jan 2004 08:39:25 -0800, Norman ELton wrote:
>
> I searched for strategies relating to perl running as root, but didn't
> come up with anything conclusive, other than the obvious, don't trust
> ANY input. Validate everything.
>
> Any other ideas?
Have you read perldoc perlsec? It's a good start.
--
Rocco Caputo - rcaputo@pobox.com - http://poe.perl.org/
------------------------------
Date: 23 Jan 2004 06:45:44 -0800
From: elnormo@hotmail.com (Norman ELton)
Subject: Re: Running a daemon as root
Message-Id: <a67295c3.0401230645.148f2802@posting.google.com>
I have, but it's been a while. I'll get a refresher. Thanks.
Norman
Rocco Caputo <troc@pobox.com> wrote in message
>
> Have you read perldoc perlsec? It's a good start.
------------------------------
Date: 21 Jan 2004 07:08:40 -0800
From: naveen_reddy_2004@hotmail.com (Naveen Reddy)
Subject: Re: Running Another Application
Message-Id: <dec0b6c6.0401210708.563b49cc@posting.google.com>
Thanks everbody for your responses.
> Thanks for your time,
> Reddy
------------------------------
Date: Wed, 21 Jan 2004 08:14:48 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Running Perl script on Windows NT
Message-Id: <slrnc0t2ao.6nv.tadmc@magna.augustmail.com>
Pea <taralish@yahoo.com> wrote:
> Thanks for all of the tips.
Here is one more:
Do not top-post!
Have you seen the Posting Guidelines that are posted here frequently?
[ snip 65 lines of TOFU ]
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Thu, 22 Jan 2004 20:45:35 -0000
From: "gnari" <gnari@simnet.is>
Subject: Re: Script that blocks certain IP's
Message-Id: <bupcv0$3vb$1@news.simnet.is>
"Dino" <no.sec@tin.it> wrote in message
news:f8ebbc.0401210051.5eb830fe@posting.google.com...
[snipped how exiting if $ENV{REMOTE_ADDR} eq '192.168.1.1') fails]
> when i put this line : if ($ENV{REMOTE_ADDR} eq '192.168.1.1') { exit
> } on the top of the script, does it check the REMOTE_ADDR from the
> apache server? Because i got the feeling that the $ENV{REMOTE_ADDR} is
> empty.
> What more info can i supply ?
well, you could just print out the contents of %ENV
just put somewhere in the script, preferably just after the
HTML <BODY> tag has been printed:
for my $k (keys %ENV) {print "ENV [$k]=[$ENV{$k}]<br>\n";}
gnari
------------------------------
Date: Thu, 22 Jan 2004 21:46:21 +0000
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: Script that blocks certain IP's
Message-Id: <Pine.LNX.4.53.0401222138420.17353@ppepc56.ph.gla.ac.uk>
On Thu, 22 Jan 2004, gnari wrote:
> just put somewhere in the script, preferably just after the
> HTML <BODY> tag has been printed:
> for my $k (keys %ENV) {print "ENV [$k]=[$ENV{$k}]<br>\n";}
Which is going to produce some exciting results if the resulting
strings contain markup!!
I'd apply CGI::escapeHTML() to what's going to be printed
(except for the <br>, natch; although personally I would
put the result in a <pre> element and then use \n between
the lines, but I guess that's just a matter of taste really).
cheers
------------------------------
Date: Thu, 22 Jan 2004 22:42:37 -0000
From: "gnari" <gnari@simnet.is>
Subject: Re: Script that blocks certain IP's
Message-Id: <bupjqe$4nc$1@news.simnet.is>
"Alan J. Flavell" <flavell@ph.gla.ac.uk> wrote in message
news:Pine.LNX.4.53.0401222138420.17353@ppepc56.ph.gla.ac.uk...
> On Thu, 22 Jan 2004, gnari wrote:
>
> > just put somewhere in the script, preferably just after the
> > HTML <BODY> tag has been printed:
> > for my $k (keys %ENV) {print "ENV [$k]=[$ENV{$k}]<br>\n";}
>
> Which is going to produce some exciting results if the resulting
> strings contain markup!!
>
> I'd apply CGI::escapeHTML() to what's going to be printed
> (except for the <br>, natch; although personally I would
> put the result in a <pre> element and then use \n between
> the lines, but I guess that's just a matter of taste really).
>
sure, but this was only supposed to be a run once, see what we
got here and then rollback to previous version kind of test,
just to get the idea of what kind of beasts lurk in %ENV.
I would be really surprised there is there is any markup there,
specially as he would be doing the test request himself.
anyways I was just prompting the OP to do some elementary
debugging himself, before just telling us that it does not work.
gnari.
------------------------------
Date: 22 Jan 2004 23:42:23 -0800
From: no.sec@tin.it (Dino)
Subject: Re: Script that blocks certain IP's
Message-Id: <f8ebbc.0401222342.77f15591@posting.google.com>
"gnari" <gnari@simnet.is> wrote in message news:<bupjqe$4nc$1@news.simnet.is>...
> "Alan J. Flavell" <flavell@ph.gla.ac.uk> wrote in message
> sure, but this was only supposed to be a run once, see what we
> got here and then rollback to previous version kind of test,
> just to get the idea of what kind of beasts lurk in %ENV.
>
> I would be really surprised there is there is any markup there,
> specially as he would be doing the test request himself.
>
> anyways I was just prompting the OP to do some elementary
> debugging himself, before just telling us that it does not work.
>
> gnari.
hi guys, thanks for the response.
The $ENV{REMOTE_ADDR} gives me back the IP-adress of the webserver
that is hosting my website, and not the adress of the user logged into
the site. Why? i thought that REMOTE_ADDR or REMOTE_HOST should give
me back the logged user'S IP, not that from the webserver...what am i
missing?
------------------------------
Date: 23 Jan 2004 00:00:13 -0800
From: no.sec@tin.it (Dino)
Subject: Re: Script that blocks certain IP's
Message-Id: <f8ebbc.0401230000.61ed6d70@posting.google.com>
"Tintin" <me@privacy.net> wrote in message news:<bulksq$j1d3m$1@ID-172104.news.uni-berlin.de>...
> "Dino" <no.sec@tin.it> wrote in message
> news:f8ebbc.0401210127.68252a20@posting.google.com...
> > P.S.
> >
hi guys,
id did that:
my @ips = ("1.1.1.1","2.2.2.2","3.3.3.3","4.4.4.4","5.5.5.5");
print "Content-type: text/plain\r\n\r\n<br>"; # just in case
print "[\$ENV{'REMOTE_ADDR'}] is [$ENV{'REMOTE_ADDR'}] \n<br>\n";
foreach my $ip (@ips){
print "\$ip is $ip, $ENV{'REMOTE_ADDR'} eq $ip gives "
, $ENV{'REMOTE_ADDR'} eq $ip , "\n <br> \n";
}
after i click on the "submit" button and the guestbook-script gets
executed
(this is the first part of the output on the reloaded page):
<br>[$ENV{'REMOTE_ADDR'}] is [xxx.xxx.xxx.xxx]
<br>
$ip is 1.1.1.1, xxx.xxx.xxx.xxx eq 1.1.1.1 gives
<br>
$ip is 2.2.2.2, xxx.xxx.xxx.xxx eq 2.2.2.2 gives
<br>
Content-type: text/html
.....
So, the $ENV{'REMOTE_ADDR'} gives me back xxx.xxx.xxx.xxx, which is
the IP of the server the site is in!
i do not need that IP, but the IP of the guest who is actually logged
and tryin' to sign in. why does
REMOTE_ADDR not get back the guest's IP from apache webserver? is
REMOTE_ADDR the wrong call?
thanks
Dino
p.s. of course, i'm not testing from the same machine the site is in
------------------------------
Date: Fri, 23 Jan 2004 17:29:03 +0900
From: ko <kuujinbo@hotmail.com>
Subject: Re: Script that blocks certain IP's
Message-Id: <buqma4$inl$1@pin3.tky.plala.or.jp>
Dino wrote:
[snip]
> So, the $ENV{'REMOTE_ADDR'} gives me back xxx.xxx.xxx.xxx, which is
> the IP of the server the site is in!
This doesn't have anything to do with Perl, but if what you say is true
then $ENV{REMOTE_ADDR} is probably the IP of a reverse proxy. Ask your
ISP to confirm...
HTH -keith
------------------------------
Date: Fri, 23 Jan 2004 11:20:07 +0000
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: Script that blocks certain IP's
Message-Id: <Pine.LNX.4.53.0401231112010.18603@ppepc56.ph.gla.ac.uk>
On Thu, 22 Jan 2004, gnari wrote:
> "Alan J. Flavell" <flavell@ph.gla.ac.uk> wrote in message
>
> > Which is going to produce some exciting results if the resulting
> > strings contain markup!!
> >
> > I'd apply CGI::escapeHTML() to what's going to be printed
[...]
> sure, but this was only supposed to be a run once, see what we
> got here and then rollback to previous version kind of test,
> just to get the idea of what kind of beasts lurk in %ENV.
Alright, and point taken; but when there's a right and a wrong way,
and they differ by very little, I'm afraid I'm going to favour doing
it the right way even in such simple cases, rather than deliberately
doing it the wrong way and hoping that under the restrictions of the
specific problem it won't matter. Best to start off in the right way,
rather than starting out wrong and later having to un-learn old
habits, IMHO. I've seen too many examples of scripts that were trying
to display e.g <img src="..."> - e.g in a specimen of HTML markup -
and succeeded only in displaying a broken-image placeholder, due to
forgetting to "entify" the data.
Of course an alternative approach if you only want to see the
environment report is to have the script send Content-type: text/plain
rather than text/html.
> I would be really surprised there is there is any markup there,
Nevertheless, I would not want to learn a broken way of doing things
on the pretext that it saves a little bit of typing, just in order to
have to un-learn it later.
cheers
------------------------------
Date: Fri, 23 Jan 2004 19:08:01 GMT
From: Chris <ceo@nospan.on.net>
Subject: Re: Script that blocks certain IP's
Message-Id: <lieQb.27968$fn1.5797@newssvr33.news.prodigy.com>
Dino wrote:
> "gnari" <gnari@simnet.is> wrote in message news:<bupjqe$4nc$1@news.simnet.is>...
>
>>"Alan J. Flavell" <flavell@ph.gla.ac.uk> wrote in message
>
>
>>sure, but this was only supposed to be a run once, see what we
>>got here and then rollback to previous version kind of test,
>>just to get the idea of what kind of beasts lurk in %ENV.
>>
>>I would be really surprised there is there is any markup there,
>>specially as he would be doing the test request himself.
>>
>>anyways I was just prompting the OP to do some elementary
>>debugging himself, before just telling us that it does not work.
>>
>>gnari.
>
>
> hi guys, thanks for the response.
> The $ENV{REMOTE_ADDR} gives me back the IP-adress of the webserver
> that is hosting my website, and not the adress of the user logged into
> the site. Why? i thought that REMOTE_ADDR or REMOTE_HOST should give
> me back the logged user'S IP, not that from the webserver...what am i
> missing?
Check to see if your ISP is using a "reverse proxy." If it is, you
could be dead on using REMOTE_ADDR. You could check to see if there is
a FORWARDED_FOR or HTTP_FORWARDED_FOR or other such variable. This
would contain the address you are looking for perhaps. If reverse proxy
is being used, you are going to have to do this differently.
One way would be to have client-side code on your page that
automatically sets a hidden variable with the end user's true IP address
so that when the page POSTs to your web server, the end user's IP gets
passed to you as a form variable. This would "pass thru" a reverse proxy.
This would involve client-side script (like JavaScript) which could be
turned off on the client-side, thereby circumventing your sniff of their
address, but it is one way to handle the reverse proxy in the absence of
any additional HTTP headers (like the FORWARDED_FOR variable). If you
want help with THAT, you would have to go to another NG. Or, I suppose
I could drop some quick JS code out here if it turns out that in your
case that this is what you need. (It would annoy some who probably
already hold the opinion that your problem is being removed more and
more from Perl -- which is hard to argue with.)
Chris
-----
Chris Olive
chris (-at-) technologEase (-dot-) com
http://www.technologEase.com
(pronounced "technlogies")
------------------------------
Date: Sat, 24 Jan 2004 14:04:58 +0000
From: pkent <pkent77tea@yahoo.com.tea>
Subject: Re: Script that blocks certain IP's
Message-Id: <pkent77tea-2282F9.14045824012004@pth-usenet-01.plus.net>
In article <f8ebbc.0401222342.77f15591@posting.google.com>,
no.sec@tin.it (Dino) wrote:
> The $ENV{REMOTE_ADDR} gives me back the IP-adress of the webserver
> that is hosting my website, and not the adress of the user logged into
> the site. Why? i thought that REMOTE_ADDR or REMOTE_HOST should give
> me back the logged user'S IP, not that from the webserver...what am i
> missing?
No, REMOTE_ADDR (on Apache at least) gives you the address at the other
end of the TCP connection through which the request came.
If your server is doing a ProxyPass to itself then obviously the request
is coming from the webserver back into itself, and therefore the other
end of the TCP connection is the webserver.
You might check this by looking at the port number that you connect to,
the port number that is actually in SERVER_PORT, looking at things like
REQUEST_URI to see if they match what's in your browser, or just read
the httpd.conf.
If you are being ProxyPassed then there is a way to take environment
vars in the proxy server and append them to the querystring which goes
to the backend server.
P
--
pkent 77 at yahoo dot, er... what's the last bit, oh yes, com
Remove the tea to reply
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 6044
***************************************
