[Lingmei Pan]

Thanks for your suggestions.  I too, ended up putting the DB login info in an .ini file under the site root directory.

[Lingmei Pan]

This is what I do:

Code:

 # ‘run’ mode always has a MSGID; fetch and process it
 keylget args MSGID mh;

 set msg [msgget $mh];

 #set the output file name = OriginalFileName.hc
 set extension “hc”;

 #parse inbound filename from DRIVERCTL
 set driverCTL [msgmetaget $mh DRIVERCTL];
 set ibFilePath [keylget driverCTL FILENAME];

 set index [string first “/” $ibFilePath];
 set ibFileName [string range $ibFilePath [expr $index+1] end];

 set index [string first “.” $ibFileName];
 set obFileName [string range $ibFileName 0 [expr $index-1]];
 set obFileName $obFileName.$extension;

 set driverControlString “{FILESET {{OBFILE $obFileName}}}”;
 msgmetaset $mh DRIVERCTL $driverControlString;
 
 lappend dispList “CONTINUE $mh”;

[Lingmei Pan]

Entering the parameters in the box will not be a feasible solution in our case, as the Cloverleaf site will be administered by our customers’ IT personnel.  Thanks though for your input.

[Lingmei Pan]

That’s what I am trying to do, but how do you pass the parameters?  By reading from a file?

[Lingmei Pan]

Humm… I wonder what that is.   😉   Incorporating information gathering in the installer is a very good option.

Thanks for chipping in, Kevin.  All thoughts help.

[Lingmei Pan]

There will not be direct interaction between the general users and Cloverleaf site.  The process will run transparently behind the scene.  I guess the word “user” in my previous posts was misleading. It actually meant the person (IT personnel) who sets up and starts the Cloverleaf threads/process.  

The site I am developing is doing the regular stuff:  reading messages from a file, mapping and cleaning up a bit, forwarding and writing the messages to a file.  I should probably clarify that the site will not be used internally.  It will be distributed to different clinics/customers.

Supplying username and password for database login should only be one-time deal (unless the login changes), during the installation/set up of the site.  The script is working with my hard-coded username and password.  When the customers receive the site, I just don’t think it is a good idea for them to enter their username and password in the script.  It is not very secure to have them enter them in a flat file.  So, the encrypted configuration file seems to be the way to go.

If the site is for internal use, hard-coding the login is not an issue at all.  John, how do you usually implement this?

Thank you!

[Lingmei Pan]

The Cloverleaf site that I am developing receives HL7 messages from one system, processes them, then sends the messages to another system.  During processing, I need to query the SQL database to retrieve additional data based on the patient and provider IDs received in the message.  To establish the connection to the database, the script calls SQLConnect $hdbc $dsn SQL_NTS $usr SQL_NTS $passwd SQL_NTS, which requires database login.  There should only be one login for the same datasource.

It looks like the “simplest” solution to avoid hard-coding username and password in the script is to read them from odbc.ini or an encrypted configuration file.  

Thanks for your suggestions.

[Lingmei Pan]

Kevin, thanks for your reply.

Since the same site will be used by different customers who have different username and password to access their databases, I am trying to find a way to not having the customer go into the tcl script to change the hard-coded username and password.

A colleague’s past experience with another interface engine was to have the user configure their username and password (which would then be encrypted) upon set up.

I am just wondering if there is a way in Cloverleaf to get around hard-coded username and password, and how people usually implement it.

Thank you!

[Author]

Replies