Get remote IP in self-calling script

[Markus R. Keßler]

Hi there,

I've written a little perl script that handles text like a webmail gui
does. It is accessible via webbrowser from the internet.

When the script is invoked without parameter if creates the neccessary
html code for a kind of input mask for entering the text, as well as the
buttons for "send" etc. So there's no need for a html file creating the
input form and from which the script is invoked.

It _does_ work, so far.

But, because the script is called from itself, $ENV{'REMOTE_ADDR'} always
writes the IP of the _SERVER_ into the logfile, rather than the user's
one :-(

Any idea how to get around that?

Thanks for any hint!

Best regards,

Markus

 

[Jochen Lehmeier]

But, because the script is called from itself,
Why?

Any idea how to get around that?

If you do a local http request on the server (using LWP, I assume), then
there is no sane way to fake another IP address into the logfile of your
web server. You could of course pass the original IP in a CGI parameter
and log it yourself. But why would you do a local http request in the
first place? I've done this in some cases where some script uses another
one, but calling *itself* seems not necessary.

Thanks for any hint!

Show your code...

 

[Markus R. Keßler]

Am Mon, 14 Dec 2009 22:21:54 +0100 schrieb Jochen Lehmeier:

Why?

I just want to have one file doing the job.
When I started writing web applications in most cases I wrote a html file
which invoked a perl script, but this way I always had to modify two
files for any changes. I had to modify the html one for changing the
layout, and I had to modify the perl script which handled the input from
the htm file.

If you do a local http request on the server (using LWP, I assume), then
there is no sane way to fake another IP address into the logfile of your
web server. You could of course pass the original IP in a CGI parameter
and log it yourself. But why would you do a local http request in the
first place? I've done this in some cases where some script uses another
one, but calling *itself* seems not necessary.

Well, I already thought about passing the IP within a "hidden" variable
from the calling instance of the script to the called one.
Sure, this would work, but in that case I rely on a variable that could
be faked when calling the script via curl etc.

Show your code...

For instance, this

http://www.dipl-ing-kessler.de/developer/freigabe/compat/index.htm

is an example of one of my self-calling scripts.

Best regards,

Markus

 

[J. Gleixner]

Am Mon, 14 Dec 2009 22:21:54 +0100 schrieb Jochen Lehmeier:


I just want to have one file doing the job.
When I started writing web applications in most cases I wrote a html file
which invoked a perl script, but this way I always had to modify two
files for any changes. I had to modify the html one for changing the
layout, and I had to modify the perl script which handled the input from
the htm file.

That's usually a good design, if the template is flexible enough
to handle different parameters. Look at using a template module. Plenty
to choose from on CPAN. Template, HTML::Simple, HTML::Mason, etc.
or simply use the CGI module to generate your HTML.

Well, I already thought about passing the IP within a "hidden" variable
from the calling instance of the script to the called one.
Sure, this would work, but in that case I rely on a variable that could
be faked when calling the script via curl etc.


For instance, this ....

is an example of one of my self-calling scripts.

ahhhh.. that's not your code, that's possibly the output of
your code. Show us the code for your program. You don't have to
post everything, simply make a small/short script that
would show us what you're currently doing.


You can pass arguments to your program, instead of
doing another HTTP request.

perldoc perlopentut
perldoc IPC::Open3
perldoc -f system
perldoc -f do

 

[Jochen Lehmeier]

I just want to have one file doing the job.

You mean your script outputs the <form> if there are no input parameters;
if there are input parameters (as submitted by the form) you process them.

That's fine and standard.

If you say "the script is called from itself" I interpret it as "the
script calls itself" (maybe using system()) or whatever; also, for your
server's IP to appear in the Apache (?) logfile, the HTTP connection for
the request would have to originate from the server. But, looking at your
source code, it looks like I misunderstood you there.

For instance, this

http://www.dipl-ing-kessler.de/developer/freigabe/compat/index.htm

You really want to use CGI instead of doing all of the basic CGI stuff
yourself.

I also fail to see how you could end up with your server's IP in the
logfile. The second request seems to come from the browser just fine, so
Apache should log the user's IP.

 

[Markus R. Keßler]

Am Mon, 14 Dec 2009 23:14:37 +0100 schrieb Jochen Lehmeier:

You mean your script outputs the <form> if there are no input
parameters; if there are input parameters (as submitted by the form) you
process them.

Yes, that's what the script does!

So it was slightly misleading to say "self-calling". Sorry.

That's fine and standard.

If you say "the script is called from itself" I interpret it as "the
script calls itself" (maybe using system()) or whatever; also, for your
server's IP to appear in the Apache (?) logfile, the HTTP connection for
the request would have to originate from the server. But, looking at
your source code, it looks like I misunderstood you there.

I also fail to see how you could end up with your server's IP in the
logfile. The second request seems to come from the browser just fine, so
Apache should log the user's IP.

Yes, there's the Apache logfile also, which shows the "real" IP in one
line when the script is called for the first time and without parameter.

And the following line, when clicking on "submit" the "remote address"
environment variable contains the IP of the server.

So, getting the "real" user's IP can be easily done by grepping the
Apache logfile. But:

- for convenience purposes I'd like to have a separate logfile

- the user could load the script (without parameters) and leave the
browser for any time period.
So, when clicking the "submit" button, let's say, hours later, it would
be nearly impossible to determine which call of the script (with
parameters) is related to the first call with the "real" user's IP.

The background is: I wrote a little "diary" application which stores my
ideas, and, at least I want to see which "hacking attempts" occur to this
application. That's the point.

Any idea how to get the "real" IP at _any_ time the script is called
directly or indirectly?

Best regards,

Markus

 

[Jochen Lehmeier]

And the following line, when clicking on "submit" the "remote address"
environment variable contains the IP of the server.

How is that possible? If the user clicks "submit", the user's browser
connects to your Apache, which logs the remote IP (all this does not
involve Perl yet, as your web server will log independent from what
happens inside the CGI script).

Any idea how to get the "real" IP at _any_ time the script is called
directly or indirectly?

The remote IP should already be logged, and a workaround should absolutely
not be necessary.

Maybe you could make your code as short as possible (i.e., reduce
everything to the barest minimum of stuff; only one input field etc.).
Post your perl code together with the two form HTML page (the first one,
which is displayed when there are no CGI parameters) and the log file
snippet for the two requests. Then we can take a look at it.

 

[Markus R. Keßler]

Am Mon, 14 Dec 2009 23:59:49 +0100 schrieb Jochen Lehmeier:

How is that possible? If the user clicks "submit", the user's browser
connects to your Apache, which logs the remote IP (all this does not
involve Perl yet, as your web server will log independent from what
happens inside the CGI script).


The remote IP should already be logged, and a workaround should
absolutely not be necessary.

Maybe you could make your code as short as possible (i.e., reduce
everything to the barest minimum of stuff; only one input field etc.).
Post your perl code together with the two form HTML page (the first one,
which is displayed when there are no CGI parameters) and the log file
snippet for the two requests. Then we can take a look at it.

Hi all,

many thanks for all your hints and info!

Well, after reading your comments I already had the suspicion that this
effect most likely could have something to do with a half- assed
implementation of an SSL certificate.

And in fact to load a page via ssl, no matter if html or perl, the
customers of my ISP have to write the prefix

"https://ssl1.fritsch-hosting.de/"

in front of the url to, for instance, read

"https://ssl1.fritsch-hosting.de/www.dipl-ing-kessler.de/cgi-bin/diary.pl"

Experimentally I just removed this "prefix" and invoked the script over
http rather than https - and in this case every demanded file is logged
correctly!

Well, I just have no clue what goes on "inside" this SSL implementation
and why apache behaves like this. Also, I have no idea how to get this
box to behave correctly with SSL.

Or, is this normal behaviour when running https / mod_ssl? - The box is a
"lamp" machine with apache and several virtual servers with shared IPs,
mod_ssl, perl etc., running on debian.

Thanks again,
best regards,

Markus

 

[John Bokma]

"https://ssl1.fritsch-hosting.de/www.dipl-ing-kessler.de/cgi-bin/diary.pl"
[...]

Or, is this normal behaviour when running https / mod_ssl? - The box is a
"lamp" machine with apache and several virtual servers with shared IPs,
mod_ssl, perl etc., running on debian.

You can have only one "https domain" on a given IP address [1]. What
seems to happen here is that fritsch-hosting.de proxies the other
domains via the single "https domain". The keyword is proxy here, which
means that Apache calls your script as part of the proxying, and hence
the server's IP address showing up.

[1] http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts

 

[J. Gleixner]

Am Mon, 14 Dec 2009 23:59:49 +0100 schrieb Jochen Lehmeier:


Hi all,

many thanks for all your hints and info!

Many thanks for again, not posting your example code.

Well, after reading your comments I already had the suspicion that this
effect most likely could have something to do with a half- assed
implementation of an SSL certificate.

And in fact to load a page via ssl, no matter if html or perl, the
customers of my ISP have to write the prefix

"https://ssl1.fritsch-hosting.de/"

in front of the url to, for instance, read

"https://ssl1.fritsch-hosting.de/www.dipl-ing-kessler.de/cgi-bin/diary.pl"

Experimentally I just removed this "prefix" and invoked the script over
http rather than https - and in this case every demanded file is logged
correctly!

Is the SSL traffic logged to a different file?

Well, I just have no clue what goes on "inside" this SSL implementation
and why apache behaves like this. Also, I have no idea how to get this
box to behave correctly with SSL.

Maybe you need to talk to your ISP/hosting company?

There's plenty of documentation online for setting up SSL too.

Really, though, it's very likely you are making this much more
difficult than it needs to be. If you want to get help with
your code, then show your code. Without it, we can only
guess at the problem and wasting our time.

 

[Markus R. Keßler]

Am Tue, 15 Dec 2009 17:07:04 -0600 schrieb J. Gleixner:

Many thanks for again, not posting your example code.

Hi,

I just hesitated som time before posting the code because I haven't had
the chance to completely translate it into English. A version with code
in English but comments in German is here:

http://www.dipl-ing-kessler.de/temp/sample.pl.txt

Hope, it's clear, though.

Is the SSL traffic logged to a different file?

Don't know exactly. And, in contrary to what

http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts

says, our ISP _IS_ able to provide SSL to every "v-host"- customer. but
we had been told, that providing the same certificate to all the
customers is a quick and dirty hack. We should be glad that this works at
all.

Maybe you need to talk to your ISP/hosting company?

Well, see above...

There's plenty of documentation online for setting up SSL too.

Really, though, it's very likely you are making this much more difficult
than it needs to be. If you want to get help with your code, then show
your code. Without it, we can only guess at the problem and wasting our
time.

Yes, sure. Thanks again,
best regards,

Markus

 

[Randal L. Schwartz]

Markus> When the script is invoked without parameter if creates the neccessary
Markus> html code for a kind of input mask for entering the text, as well as the
Markus> buttons for "send" etc. So there's no need for a html file creating the
Markus> input form and from which the script is invoked.

I've written hundreds of scripts like that.

My columns at http://www.stonehenge.com/merlyn/columns.html are on line.
Probably 75 of the 255 there "use CGI" for this.

Markus> It _does_ work, so far.

Markus> But, because the script is called from itself, $ENV{'REMOTE_ADDR'} always
Markus> writes the IP of the _SERVER_ into the logfile, rather than the user's
Markus> one :-(

And this is where I lost you.

If your script invoked without parameters prints:

<form action="/path/to/me"> ... </form>

and the browser submits it, you should get the proper REMOTE_ADDR.

Something is not as you say. Maybe you explained it further down the thread,
but I think the thread got a bit distracted.

 

[John Bokma]

Don't know exactly. And, in contrary to what

http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts

says, our ISP _IS_ able to provide SSL to every "v-host"- customer.

Then why do you have to use:

https://ssl1.fritsch-hosting.de/www.dipl-ing-kessler.de/cgi-bin/diary.pl
^^^^^^^^^^^^^^^^^^

instead of

https://www.dipl-ing-kessler.de/cgi-bin/diary.pl

;-). (Exactly!)[1]

Like I wrote: my best guess is that Fritsch Hosting uses
ssl1.fritsch-hosting.de as a proxy for their customers to provide
https which results in Apache connecting to dipl-ing-kessler.de, hence
the address of the server showing up since ssl1.fritsch-hosting.de and
www.dipl-ing-kessler.de are on the same server (correct?).



[1]
www.dipl-ing-kessler.de uses an invalid security certificate.

The certificate is only valid for ssl1.fritsch-hosting.de

 

[Markus R. Keßler]

Am Tue, 15 Dec 2009 19:41:15 -0600 schrieb John Bokma:

Don't know exactly. And, in contrary to what

http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts

says, our ISP _IS_ able to provide SSL to every "v-host"- customer.

Then why do you have to use:

https://ssl1.fritsch-hosting.de/www.dipl-ing-kessler.de/cgi-bin/diary.pl
^^^^^^^^^^^^^^^^^^

instead of

https://www.dipl-ing-kessler.de/cgi-bin/diary.pl

;-). (Exactly!)[1]

Like I wrote: my best guess is that Fritsch Hosting uses
ssl1.fritsch-hosting.de as a proxy for their customers to provide https
which results in Apache connecting to dipl-ing-kessler.de, hence the
address of the server showing up since ssl1.fritsch-hosting.de and
www.dipl-ing-kessler.de are on the same server (correct?).



[1]
www.dipl-ing-kessler.de uses an invalid security certificate.

The certificate is only valid for ssl1.fritsch-hosting.de

Hi!

Indeed, one can invoke a script like shown above on that machine.
I then get asked for confirming the unsigned certificate, which is valid
for ssl.fritsch-hosting.de only, but when trying to load a real
existing / working script there will occur a 404 error:

http://www.dipl-ing-kessler.de/cgi-bin/emailimg.pl

works,

https://ssl1.fritsch-hosting.de/www.dipl-ing-kessler.de/cgi-bin/
emailimg.pl

also works, but

https://www.dipl-ing-kessler.de/cgi-bin/emailimg.pl

does not. There arises a 404 error.

Best regards,

Markus