Do you use SAS/Connect? I do. I think it works really well. I've used it for many years in many situations and never found it coming up short. I would even go so far as to say it's one of the few things in SAS that is straightforward, stable and a pleasure to use.
Do you hardcode usernames/passwords into your connect scripts? Sometimes circumstances dictate it. Do you use pass-through SQL? Do you use SAS/Access libname statements? Do you think it might be a bad thing to have usernames/passwords sitting around in code?
This is something I've thought about before, and it just came up at work recently so I'm thinking about it again. As far as I know there is no facility in SAS to encrypt/decrypt script files during the SAS session (in this case, I am considering a "script file" to be anything not compiled: base sas, connect script, config files, etc). Does anyone know if there is such a mechanism?
I think I could write something to accomplish this, though it would be a little kludgy since there are no api hooks into the SAS system internals. But then, what's a little kludge between SAS programmers?
Google SAS Search
Wednesday, June 22, 2005
find . -exec fgrep -i "passw" '{}' \; -print
Subscribe to:
Post Comments (Atom)
On a slightly different approch, I use one dialog on my startup of SAS to put in a few passwords for server logons, and then I can use these passes in various logon macroes, whenever I need to logon.
ReplyDeleteAfter retrieving these passes, I simply use "proc encode" to store them in encoded form in a txt file, then read that textfile back in and store the encoded value in a macro variable.
- but I figure you're already of that procedure in SAS?
You didn't specify which operating system you are using. If it is Windows to Windows, you can use SSPI to authenticate w\o passing the username and password. You can also get around this using Integration Technologies. In fact, using IT along with some C# code, I can fully encrypt everything and also keep SAS from generating a log.
ReplyDelete