Re: VB debugging my Perl Scripts on user comp? help! Security issue!

1) Since he has VB installed on the computer, he probably has MS Visual Studio installed, which comes with MS InterDev. InterDev is a GUI debugging tool used for ASP scripts.

2) If you are using activeState perl, it comes with activePerl which is an ActiveX component, meaning you can use it as an ASP scripting language.

3) (I'm almost 100% certain this is true): your Perl script is, for all practical purposes, being seen by IIS as an ASP script. Thus, it is pulling it up in the InterDev debugger as it would a script written in ASP.

It seems to me that for some reason IIS is having a problem processing the script. I would suggest you run it on his computer, bring it up in the InterDev debugger, and see what the problem is.

Hope this helps,
davidj

Comment on Re: VB debugging my Perl Scripts on user comp? help! Security issue!

Replies are listed 'Best First'.
Re^2: VB debugging my Perl Scripts on user comp? help! Security issue! by Stenyj (Beadle) on Jul 05, 2004 at 18:13 UTC
From what my host has listed under my package, the site is hosted on a Linux machine, so (unless I'm mistkane) it shouldn't be an IIS or ActiveState problem, since I thought that ActiveState was strictly a windows version of perl, and IIS was a windows based server application. The script has been running fine for probably a year now... if not longer. Nobody else has reported this problem, and I can't find any errors in the code nor can I seem to reproduce the error (then again, I don't have VB installed... so that may be why). I'm assuming my only solution would be to setup a library below the web route, and then use a subroutine in the library to generate the connection to the database for each script? I just don't want to potentially leave my username & PW to my db out in the open (obviously). Any suggestions? Thx guys! Stenyj	[reply]
Re^3: VB debugging my Perl Scripts on user comp? help! Security issue! by bmann (Priest) on Jul 05, 2004 at 18:24 UTC
Is the server running front page extensions? If it is, someone would need a username and password to get to it. Other than that, I can think of no reason the server would serve up the source of the script (unless it's a configuration issue.) I'm assuming my only solution would be to setup a library below the web route... Yes, you should store your id & password outside of the web root.	[reply]