GhostWheel has asked for the wisdom of the Perl Monks concerning the following question:

Hi, all! I've got a quick question for you: is there a way to run a perl script on a server, while getting the IP of the user, and then generate the code for a new dynamic HTML page?

Basically
User opens page (got that)->
Perl script runs (is there a way to do it automatically, no button? and when I tried *with* a button, it didn't work)->
Perl script gets user's IP (I'm thinking by using the shell(ipconfig) command, but is there another way?)->
Perl script generates new page (got that)->
User opens new page (got that)

Sorry if it's a little garbled, it's 3:40 AM here atm ;-)

PS. Fairly new to perl, so plz explain without too much jargon :-P

Replies are listed 'Best First'.
Re: Running Perl thru HTML
by FitTrend (Pilgrim) on Mar 14, 2005 at 14:05 UTC

    Yes you can. What you can do on your webserver (I'm assuming apache) is to configure your directory with the ExecCGI directive in your httpd.conf file.

    AddHandler cgi-script .cgi DirectoryIndex index.html index.cgi index.html.var <Directory "DIR OF CHOICE"> Options Indexes FollowSymLinks ExecCGI AllowOverride none Order allow,deny Allow from all </Directory>

    Then create an index.cgi file that performs to reference the variable $ENV{'REMOTE_ADDR'} variable within your script. Then utilize that value to perform your task. Lastly, redirect the user to that page. I personally use javascript (because sometimes I refresh multiple iframes or frames) for my redirects, like:

    print qq { <script language=javascript> window.open('/dir/$ENV{'REMOTE_ADDR'}.html','','') </script> };

    Hope this helps

Re: Running Perl thru HTML
by Joost (Canon) on Mar 14, 2005 at 14:06 UTC
      What should the HTML document look like to call the PERL script?
Re: Running Perl thru HTML
by samizdat (Vicar) on Mar 14, 2005 at 14:37 UTC
    If your page actually _is_ a script, it runs upon opening, i.e. CGI or mod_perl, depending on your Apache setup. You can set it up to run a background job which does whatever, including reading from the Apache environment variables the information you want from the user's system. Once it's launched the background job, you have it print the next HTML page, which has a meta-refresh embedded in it. In the mean time, your background job completes creating its page, and the refresh sends your user to it. That's the long way, to be used only if you have lots of stuff to do. In reality, Perl can do the simple stuff you ask of it so that the dynamic stuff happens between the click and the new page appearing. It's only if you need the pages to stay visible long enough for human eyeballs to read and minds to process that you need to resort to refreshes et al.

    Short way:
    • User clicks on link http://www.mydomain.org/myperl.cgi
    • myperl.cgi reads apache ENV variables,
      generates new page,
      and displays it
    • done
    or long way:
    • User clicks on link myperl.cgi
    • myperl.cgi reads Apache ENV variables
    • launches background job with system('foo.pl', 'USERIP', '&')
      and displays intermediate page with meta-refresh tag to URL of dynamically generated page
    • bg job does whatever else it needs to do
      and generates new page as a file on filesystem
    • refresh sends user from intermediate page to new page
    • done

    A caveat is that the referrer and user variables that Apache maintains are often only those of proxies, so you will often get the ip's of AOL proxy machines as opposed to the end-user ip.

    Some links:

    http://httpd.apache.org/docs/env.html
    http://www.apachefreaks.com/apache2/env.html
    http://cgi.resourceindex.com/Documentation/Environment_Variables/
      I'm running IIS. Does this make any difference? If so, what should I do differently?
        You can run normal CGI scripts written in Perl from IIS,assuming you've also got Perl installed. I'm not sure where the equivalent of Apache ENV variables are, though. I'd start by looking at CGI.pm on CPAN, but beyond that you might need to look into the Win32:: modules.

        A better option by far -- and probably easier to -- is to ditch IIS and install Win32 Apache if you possibly can. I'm afraid I can't be much more help, as I have not kept up with Doze issues since W3.1.