Executing Perl Scripts on Intranet Server

[caconner]

I have what I hope is a small problem with a quick solution.

I've recently added a form to our Intranet that utilizes a Perl script to submit the form via email. Previously this was accomplish using some whacked out method that generated all kinds of errors.

I discovered that the Perl folder was not set up to allow users to execute the script, but we managed to fix that to a certain extent. I believe the administrator simply allowed scripts to be executed. I can submit the form with no problems - most likely because of my rights, but others that access the form are prompted for their username/password when they click the submit button and execute the script. What changes do I need to make to alleviate this annoyance?

The person who manages the server doesn't know much more about IIS than I do, so I feel I need to have a solution ready for him to implement. I'm not sure if this is related, but if I use Netscape instead of IE to view our Intranet it does the same thing.

 

[waiterm]

As far as I can tell IIS permissions are based on standard Windows permissions.

If you open up the IIS Manager Window, go to the folder(s) you wish to make public, you should be able to right-click on them and view 'Permissions'. If you are sure no-one's going to abuse your intranet site then add a new user -> Everyone and make sure they have full access rights, but ONLY do this for the root folder where the Perl scripts are located.

It would probably be useful to know what Clients and Server Operating Systems you're using as well.

Rob Waite

http://www.hostpipe.co.uk?src=TT

 

[arcnon]

It could be several things.

You need to determine if it indeed is the server, the script, a incorrect directive, SSL or whatever.

Put you a hello world script and see if it still asks for the password.

make sure there isn't htaccess on any of the folders that contain your script. Sometimes it is in the httpd.conf file instead.

Look in your httpd.conf and see if the executable directory(cgi-bin) directives are correct be careful if you make changes always back it up first. check the permissions pre and post editing.

If nothing has presented itself at this point copy the script to the open cgi-bin ie the one that isn't https. And see if your script will run there without problems.

pick it over a piece at a time and hopefully the issue will present itself