This content has been marked as final. Show 2 replies
If you migrate environments, you are going to have to do some configuration pretty much anyway you go about it. The question is what is the easiest/most straight foward so that it doesn't get missed during a migration, IMHO.1 person found this helpful
I would go with a well defined/documented "Global" config file that contains all of the information that may change. At a minimum, Usernames and passwords should be obfuscated/encrypted; however, it would be just as easy to do the whole file. Realize, that the decryption routines would be in your script code so this isn't 100% secure; however, it would prevent the casual user from quickly seeing usernames / passwords, etc. Furthermore, if you encrypted the whole file, they may not even realize there is a username/password in the file, etc.
In my mind this is the way to go...
Some other thoughts though, depending on what exactly you want to do....
Username / Password / Server could be some variation on the server name so that the script always knows how to generate them. The negative side is that you would always need to create a new user / password anytime server changes, so you are still not escaping manual labor. (Though maybe you could use an API call to create it, but then you probably need a username/password to create the user... AAaaaahhhhhhhhh)
While neat, this seems like it would suffer from James Bond syndrome. I'm going to kill you now Mr. Bond, but first I'm going to tell you all my intricate plans for world domination, put you in some ridiculous trap with an semi-obvious flaw, AND leave so that you have time to work on your escape......
Make a Web Service and then have your scripts make a Web Call (i.e. http://www.mycompany.com/GetConfigInfo.asp?secretcode=12341234123) which would return all the info you need. (username, password, servers, etc). AS LONG AS the webservice machine doesn't move around, this might be a decent way of doing it. Anyone sniffing around the local machines would find the config info; however, anyone looking at the scripts would see the call and could just open it in a web browser. You could of course secure that by looking at the source of the request and if it's not an approved server, not return the requested info; however, now you are getting into more maintenance work........
The time spent making this and potentially maintaining it probably isn't worth it.
Thanks beyerch2, its really helpful to hear some other ideas and suggestions :-) I think at present I'll be going with option 1, but options 3 sounds interesting for a bigger future project! :-) Thanks for your feedback.