search

hbwf / mybatis

Automatically exported from code.google.com/p/mybatis
0 stars 0 forks source link

Add ability to provide migration DB credentials via command line options #198

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What version of the MyBatis are you using?
3.0.3

Please describe the problem.  Unit tests are best!
If production databases need to have credentials that only a few designated 
individuals know (compliance regulations etc), then putting them in the 
properties files for the production environment creates a security problem.
You could restrict the access in the source control system (svc, perforce etc), 
but then adding e.g. a new variable that was added for other properties files 
need to be communicated to the individuals that have access.
It would be easier, if command line options exist to provide the credentials 
optionally in the command line, instead of only in the property files.

What is the expected output? What do you see instead?
If the --username= and --password= options are specified to supply the database 
credentials in the migrate command line, they are used instead of the 
user/password variables from the property file.

Please provide any additional information below.
Attached separately are the diffs and the archive with the working patch.

Original issue reported on code.google.com by taylor...@gmail.com on 7 Dec 2010 at 10:18

Attachments:

GoogleCodeExporter commented 9 years ago 
I've thought about this too, but found a snag in it:
If you provide the username/password as a parameter the shell history keeps a 
log of this and the commandline is stored in a .<?>history file.
This is not secure either.

I've implemented encryption (jasypt) and am now able to encrypt (with a salt 
string) the username/password in the properties file.
One can then encrypt the username/password on another box and copy the 
encrypted password string to the production box.
When reading the properties file the username/password are then stored in 
protected variables and used when needed to create the connection.

....
  protected void getConnectInfo() {
    if ("unknown".equals(environment)) {
      throw new MigrationException("Please use the --env option to specify an environment name for the connection.");
    }
    try {
      Properties props = environmentProperties();
      this.db_driver = props.getProperty("driver");
      this.db_url = props.getProperty("url");
      EncryptCommand myEncryption = new EncryptCommand();
      this.db_username = myEncryption.DecryptedString(props.getProperty("username"));
      this.db_password = myEncryption.DecryptedString(props.getProperty("password"));
    } catch (Exception e) {
      throw new MigrationException("Error retrieving database connection information.  Cause: " + e, e);
    }
  }
...

See for the other handling the attached files.
You will need to include the Jasypt encryption library/jar file (I've used 
jasypt-1.8.jar) into your project. As I use JRE 1.5 I also needed the 
icu4j-3.4.4.jar file to support encryption. I believe as from JRE 1.6 the icu4j 
is not required anymore.

Good luck.

Original comment by michael....@gmail.com on 7 Nov 2011 at 10:56

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by eduardo.macarron on 5 Feb 2012 at 1:54

GoogleCodeExporter commented 9 years ago

Original comment by eduardo.macarron on 5 Feb 2012 at 1:55

GoogleCodeExporter commented 9 years ago

Original comment by eduardo.macarron on 5 Feb 2012 at 6:08

GoogleCodeExporter commented 9 years ago

Original comment by clinton....@gmail.com on 5 Feb 2012 at 7:12

GoogleCodeExporter commented 9 years ago 
Please prvide asking of username/password parameters using Console class in 
command line.

Original comment by dmitry.s...@gmail.com on 18 Jun 2012 at 1:44

GoogleCodeExporter commented 9 years ago

Original comment by chengt on 15 Aug 2012 at 7:57

GoogleCodeExporter commented 9 years ago 
There problem with your encryption scheme, is that the password needed to 
decrypt the password is harded coded in a java class file on the filesystem.  
So anyone with access to the file system can get the password. So this does not 
improve security compared with passing it on the commandline.

Of course the commandline has the problem that anyone can see the password in 
the process list.  having the app prompt for the password solves that, but then 
you can't automate it.

My proposal would be for the password to be optionally stored in a second file. 
 The <environment>.properties could be held in source control with all the 
other settings, but the db password would be loaded from a second file that is 
not in source-control and only lives as a secure file on the server where the 
migration will be run.

Original comment by danthepe...@gmail.com on 1 Dec 2014 at 12:40