Hey....thanks for the feedback.<br><br>Unfortunately, the infrastructure of where I am does not support the maintenance of encrypted passwords or a configuation file that is solely owned by the administrators. Because of that, the solutions that you are suggesting, which seems to me to be the right way to go, will not work. However, we did decide to address the situation by requesting the user executing the script to provide a password. That way, the password is not stored on disk. Luckily, this is an interactive program. If this was a backend program, this solution would not work, and I would advise the administrators to start looking into the solutions that you suggested.
<br><br>Thanks for participating in this discussion. That is the thing that I love about community - participation and free flowing knowledge.<br><br><span style="font-weight: bold; text-decoration: underline;">Useful Perl Tip
<br></span>When implementing this interactive application, I didn't want the password to end up in the clear on the screen. I did some googling, and I found a way to hide text that is entered through the STDIN. By executing the following, I was able to prevent the password from showing up on the command prompt:
<br><br>system('stty', '-echo');<br>chop($passwd = <STDIN>);<br>system('stty', 'echo');<br><br><br>Thanks<br>Carlus<br><span style="font-weight: bold; text-decoration: underline;"><span style="text-decoration: underline;">
<span style="font-weight: bold;"></span></span><br></span><div><span class="gmail_quote">On 7/24/07, <b class="gmail_sendername"><a href="mailto:mheusser@charter.net">mheusser@charter.net</a></b> <<a href="mailto:mheusser@charter.net">
mheusser@charter.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Sean covered it pretty well for our current company. I believe there is a config file hidden somewhere that stores the passwords in some encrypted format.
<br><br>So, from the dev to test to prod, the perl code is the same, but the password file is different. Thus, even if developers hack the config file, all they get in dev and test are the dev and test pwds. (Not that we would ever do that, Tim)
<br><br>We also have a way of connecting to the appropriate db. For example, you have the same dbname in dev, test, and prod. Or you could just connect directly to the 'real' dev db. This can be helpful when you are developing in test or testing in dev - and yes, we do that on occasion. For example, if a project is in the dev phase, and the dev db goes down for two days for a refresh, and we don't want to stop working.
<br><br>But that's just me talking.<br><br>Hey, I'm curious - is anybody on this list from Luddington or Traverse City?<br><br>--heusser<br>_______________________________________________<br>grand-rapids-pm-list mailing list
<br><a href="mailto:grand-rapids-pm-list@pm.org">grand-rapids-pm-list@pm.org</a><br><a href="http://mail.pm.org/mailman/listinfo/grand-rapids-pm-list">http://mail.pm.org/mailman/listinfo/grand-rapids-pm-list</a><br></blockquote>
</div><br><br clear="all"><br>-- <br>Carlus Henry<br>SageTech L.L.C.<br><a href="http://www.sagetech-llc.com">www.sagetech-llc.com</a> | <a href="http://jdcarlflip.blogspot.com/">http://jdcarlflip.blogspot.com/</a>