Steve,
A way that we did it was to create an encrypted file which contained the
connection info. It could be a single file, similar to an SSH's known_hosts
file. For our application we had multiple files, one for each server/username
combination. It was probably not the most efficient, but with the time I had to
invest in it, it worked well.
The code had only two direct interfaces (read and write) and a few supporting
subroutines (login and generate). By passing the server and username to the
login subroutine, the correct file was opened, the encrypted data was read in,
decrypted, and then passed to ars_Login.
The benefit is that individual users could generate encrypted files and use
their own ARS login to get tasks done without the need for a single login which
reduces traceability.
HTH,
Mark Vaughan
RSP
----- Original Message -----
From: "Steve McDonald" <steve_mcdon...@choicehotels.com>
To: arsperl-users@arsperl.org
Sent: Wednesday, June 24, 2009 9:36:49 AM GMT -07:00 US/Canada Mountain
Subject: [Arsperl-users] Best Practices Question
Good day all!
Like most programmers, I like to write code that is as portable across my
dev/qa/production environments as possible. I've played with passing
arguments in workflow as well as reading control records located on each server
and each have their pluses and minuses. How have you all handled this in your
environments when supplying the servername/username/password/misc for the code
you write? Is there a better way I've overlooked?
Solaris 10
Informix 10
ARSystem 7.1
As always, I appreciate your expertise.
Steve McDonald
Sr. Remedy Applications Programmer
Choice Hotels International
------------------------------------------------------------------------------
-- Arsperl-users mailing list Arsperl-users@arsperl.org
https://lists.sourceforge.net/lists/listinfo/arsperl-users
------------------------------------------------------------------------------
--
Arsperl-users mailing list
Arsperl-users@arsperl.org
https://lists.sourceforge.net/lists/listinfo/arsperl-users
