[prog] Calling a perl program from within PHP

Jacinta Richardson jarich at perltraining.com.au
Fri Nov 12 17:57:08 EST 2004


Gareth Anderson wrote:
> Hi,
> 
> I'll state both of my problems in case their are any creative solutions :).
> 
> Currently I've created a CGI (perl) script to organise an online signatory list.
> This list is going to tie into an authcate username/password system at
> monash university australia.

Yay!

> Problem(s) 1
> 
> Cannot have a .htaccess file (which would easily do the
> authentication) in a cgi-bin directory.

This is not strictly true.  However it may be true -in your case- if 
your system administrator has set:

Allow Override = 0

in the Apache config.  You might get somewhere by asking them nicely if 
they could please allow you to have .htaccess files in *your* cgi-bin.

> Cannot have a cgi script outside the cgi-bin directory (but can have
> .htaccess outside there).

Yup.  Although once again, this is configurable.

> Cgi-wrap removes what I'm trying to get (the username).

CGI wrap shouldn't remove a username.  It does have an unfortunate 
tendency to panic and die whenever something is printed to STDERR but it 
shouldn't eat your data.

What are you seeing when this occurs.

I might be thinking of a different program here.  Maybe.

> Note that I require the username to make sure signatures are unique
> and not faked.
> So AFAIK its a dead-end considering the way things are setup, other
> people have found this too from what I've discussed (excluding maybe
> doing the authentication in perl which I don't understand).

You could do form-based + cookies authentication.  This is usually nicer 
than .htaccess and has the advantage that if your site is accessed at a 
public workstation then failure to close down the browser does not 
*necessarily* mean that identity spoofing can occur.

It's much easier to log someone out of a system by expiring their 
session ID and cookie than to attempt to expire their basic auth.
Apache::Session is probably a module worth looking into.

> Problem 2
> Currently that server listed above doesn't support PHP, I'm going to
> switch to one that does.

Coolies.

> But everything I've written is in perl, and ideally I would use a
> .htaccess and PHP file to call the perl executable or call it via
> cgi-wrap as a CGI program.

Hmm.  Perl can use Java libraries and Python libraries and Ruby 
libraries (plus many more).  Many of those languages can use Perl 
libraries too.  However, Perl and PHP don't mix as well together.

Strictly speaking trying to use 2 cgi programming languages together 
doesn't work very well.  PHP, Perl or even C and Java.

The problem is that the cgi program expects a certain setup including a 
host of environment variables, input on STDIN and STDOUT to be the 
webpage.  Calling one from the other is therefore necessarily ugly.

Having said that, it's easier to call Perl this way from PHP than the 
reverse.  I'd do something like:

<?
       /* Set up any extra environment bits */
       system('/usr/bin/perl myprogramname');

       /* Do anything that needs doing */
?>

> Calling it as a CGI program might be a bad idea though because I'd
> have to have the form in plain html (I would add the $REMOTE_USER as a
> hidden parameter) with all the information, could I easily prevent
> anyone from executing the CGI program manually (ie. allow only this
> script to call my CGI program?).

Absolutely.  If you set your Perl script to be non-executable, you can 
still execute it by calling the perl interpretor directly, as I have 
done above.

Having said all of that, If your PHP script can work, I'd be seriously 
wondering why your Perl script cannot.  It means one of the enviroments 
is probably badly setup.

> ***Or***
> I could get the PHP to grab the $REMOTE_USER variable and everything I
> need from the form and maybe pass it as command line parameters to a
> perl script which would take care of storing the data (although now
> its no longer a CGI script).

Yes, you could do that.

> The perl script would be executable by myself only or something to
> prevent outsiders from faking signatures....(and could only be called
> by the PHP script which processes the form).

It'll need to be executable by the process which runs the PHP script, or 
you need to make it readable by this process and then execute it by 
calling the interpretor.

> Is there any easy way to do it so the perl script can output to the
> user (ie. when it prints it actually gets outputted to a webpage like
> a CGI-script)?

Calling system should (please double-check) fork such that the new 
process's STDOUT goes to your original STDOUT which should achieve what 
you want.

> Because currently the perl script does output webpages with the
> results of what has being done, an ideal solution would be that I
> could still do this and have the .htaccess work.
> 
> The reason for not using 100% PHP is the persistent hash on perl makes
> programming (adding/removing not having duplicates) incredibly simple.
> 
> Sorry for the lack-of-details, there are a variety or problems I've
> hit and they're difficult to explain.
> 
> I think PHP has a exec() option? Would that work?

Yes that would probably work as well.  And if you don't need anything 
else done after you call the Perl program then exec is probably better.

> Any ideas?
> 
> Note: This does not in any way relate to assessed work (assignments etc. etc.)

Heh.  I can see that with your username, you could hit that assumption.

All the best,

    Jacinta

-- 
    ("`-''-/").___..--''"`-._          |  Jacinta Richardson         |
     `6_ 6  )   `-.  (     ).`-.__.`)  |  Perl Training Australia    |
     (_Y_.)'  ._   )  `._ `. ``-..-'   |      +61 3 9354 6001        |
   _..`--'_..-_/  /--'_.' ,'           | contact at perltraining.com.au |
  (il),-''  (li),'  ((!.-'             |   www.perltraining.com.au   |




More information about the Programming mailing list