«

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

--
Please reply to group only.
For private email please use http://www.dipl-ing-kessler.de/email.htm

On Mon, 14 Dec 2009 22:14:24 +0100, Markus R. Keßler <>
wrote:

> 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...

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

> On Mon, 14 Dec 2009 22:14:24 +0100, Markus R. Keßler <>
> wrote:
>
>> But, because the script is called from itself,
>
> 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.

>> 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.

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/devel...mpat/index.htm

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

Best regards,

Markus

--
Please reply to group only.
For private email please use http://www.dipl-ing-kessler.de/email.htm

Markus R. Keßler wrote:
> Am Mon, 14 Dec 2009 22:21:54 +0100 schrieb Jochen Lehmeier:
>
>> On Mon, 14 Dec 2009 22:14:24 +0100, Markus R. Keßler <>
>> wrote:
>>
>>> But, because the script is called from itself,
>> 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.

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.

>
>>> 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.
>
> 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
....
>
> 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

On Mon, 14 Dec 2009 22:41:45 +0100, Markus R. Keßler <>
wrote:

>>> But, because the script is called from itself,
>>
>> Why?
>
> 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/devel...mpat/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.

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

> On Mon, 14 Dec 2009 22:41:45 +0100, Markus R. Keßler <>
> wrote:
>
>>>> But, because the script is called from itself,
>>>
>>> Why?
>>
>> 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.

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

--
Please reply to group only.
For private email please use http://www.dipl-ing-kessler.de/email.htm

On Mon, 14 Dec 2009 23:49:39 +0100, Markus R. Keßler <>
wrote:

> 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.

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

> On Mon, 14 Dec 2009 23:49:39 +0100, Markus R. Keßler <>
> wrote:
>
>> 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.

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

--
Please reply to group only.
For private email please use http://www.dipl-ing-kessler.de/email.htm

"Markus R." Keßler <> writes:

> "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...aq.html#vhosts

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

Markus R. Keßler wrote:
> Am Mon, 14 Dec 2009 23:59:49 +0100 schrieb Jochen Lehmeier:
>
>> On Mon, 14 Dec 2009 23:49:39 +0100, Markus R. Keßler <>
>> wrote:
>>
>>> 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.
>
> 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.