This is a poor security solution. All I would have to do to get the username and password to your database would be to run:
include("$ADDIN_HOME(com.mydept.myapp)\Get DSN_CREDENTIALS.jsl");
::my_dsn_credentials;
Whats stored in ::my_dsn_credentials will be displayed in the log file in plain text. Not to mention storing the credentials all in one place as global variables, I could easily run this:
include("$ADDIN_HOME(com.mydept.myapp)\Get DSN_CREDENTIALS.jsl");
show globals();
Now I have all the database information stored in Get DSN_CREDENTIALS.jsl, even databases not used in the original script I received. This second portion can be fixed easily by changing all "::" to "__" (double-underscore), thus, ::my_dsn_credentials becomes __my_dsn_credentials. This will hide the global variables from being displayed in the show globals(); function. However, this still doesn't solve the issue where the specified database is compromised. This can also be fixed following the format:
Get DSN_CREDENTIALS.jsl:
// Get DSN_CREDENTIALS.jsl
__my_dsn_credentials = "Driver={Oracle in OraClient11g64_home1};Dbq=MY_DATABASE;UID=MYUSERID;PWD=MYPASSWORD;";
__dbc = create database connection(__my_dsn_credentials);
// Return nothing
__my_dsn_credentials = .;
This fixes two issues. One you can pass __dbc to another script. If one runs __dbc; it will pass 'Database( "Oracle in OraClient11g64_home1(MY_DATABASE)" )' to the log for the above script. Displaying the driver and database is far less of a security threat as passing a username and password. Second, and this is important, __my_dsn_credentials is written over. This means even if they were to GUESS the variable the information is still safe.