[grand-rapids-pm-list] Environment Variables and/or Properties

Carlus Henry carlushenry at sagetech-llc.com
Tue Jul 24 07:12:31 PDT 2007


Hey....thanks for the feedback.

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.

Thanks for participating in this discussion.  That is the thing that I love
about community - participation and free flowing knowledge.

Useful Perl Tip
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:

system('stty', '-echo');
chop($passwd = <STDIN>);
system('stty', 'echo');


Thanks
Carlus

On 7/24/07, mheusser at charter.net <mheusser at charter.net> wrote:
>
> 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.
>
> 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)
>
> 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.
>
> But that's just me talking.
>
> Hey, I'm curious - is anybody on this list from Luddington or Traverse
> City?
>
> --heusser
> _______________________________________________
> grand-rapids-pm-list mailing list
> grand-rapids-pm-list at pm.org
> http://mail.pm.org/mailman/listinfo/grand-rapids-pm-list
>



-- 
Carlus Henry
SageTech L.L.C.
www.sagetech-llc.com | http://jdcarlflip.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pm.org/pipermail/grand-rapids-pm-list/attachments/20070724/82d41ab4/attachment.html 


More information about the grand-rapids-pm-list mailing list