The result of running this application
Represents the state of the '--secure' config
Represents the state of the '--secure' config
Instead of 'main', this 'apply' should run w/ a config
Instead of 'main', this 'apply' should run w/ a config
the configuration to run with
the default config to overlay the user args over.
he command-line argument flag which tells the application NOT to load the default secure config file if it exists. e.g., try running the app without the secure config.
the command-line argument to specify the path to an encrypted secure config file (e.g. MyApp --secure=.passwords.conf)
the flag which should indicate that we should prompt to setup secure configurations
exposes a main entry point which will then:
exposes a main entry point which will then:
1) parse the user args as a configuration 2) check the user args if we should just 'show' a particular configuration setting (obscuring sensitive entries) 3) check the user args if we should run 'setup' to configure an encrypted configuration
the user arguments
the configuration we are to run with
any paths for invalid/missing configurations (e.g. a 'password' field is left empty, or a hostPort field)
launch the application, which will create a typesafe config instance from the user arguments by :
launch the application, which will create a typesafe config instance from the user arguments by :
$ try to parse the user arguments into a config entry, interpreting them as key=value pairs or locations of config files $ try to load an encrypted 'secure' config if one has been setup to overlay over the other config $ try to map system environment variables as lowercase dot-separated paths so e.g. (FOO_BAR=x) can be used to override foo.bar
In addition to providing a configuration from the user arguments and environment variables, the user arguments are also checked for one of three special arguments:
$ The argument 'show=<key substring>' flag, in which case the configuration matching <key substring> is shown. This can be especially convenient to verify the right config values are picked up if there are multiple arguments, such as alternative property files, key=value pairs, etc.
$ The argument '--setup' in order to populate a password-encrypted secure config file from standard input. For example, running "MyMainEntryPoint --setup" will proceed to prompt the user for config entries which will be saved in a password-encrypted file with restricted permissions. Subsequent runs of the application will check for this file, either in the default location or from -secure=<path/to/encrypted/config>
If either the default or specified encrypted files are found, then the password is taken either from the CONFIG_SECRET if set, or else it prompted for from standard input
the user arguments
the argument to check for in order to run the secure config setup
the argument which, if 'userArgs' contains this string, then we will NOT try
the value for the key in the form <key>=<path to secure password config> (e.g. defaults to "--secure", as in --secure=/etc/passwords.conf)
Exposes a run function which checks the parsedConfig for a 'show' user setting to display the config, otherwise invokes 'run' with the parsed config.
Exposes a run function which checks the parsedConfig for a 'show' user setting to display the config, otherwise invokes 'run' with the parsed config.
This method exposes access to the secure config parse result should the application need to do something with it
the original user args
the path where the secure config should be stored
the result of the secure config user arguments
the total configuration, potentially including the secure config
a means to read/write a secure (encrypted) config
displays the value for the given config for when the 'show' command-line arg was specified
displays the value for the given config for when the 'show' command-line arg was specified
the value to show
the config value at a particular path
A convenience mix-in utility for a main entry point.
It parsed the user arguments using the default config (which is ConfigFactory.load() but w/ system environment variables overlaid)
If the config has a 'show=<path>' in it, then that path will be printed out and the program with return.
e.g. MyAppWhichExtendsConfigApp show=myapp.database.url
will display the value of myapp.database.url
It also interprets a single '--setup' to enable the configuration of sensitive configuration entries into a locally encrypted file.
Subsequent runs of your application would then use '--secure=path/to/encrypted.conf' to load that encrypted configuration and either take the password from an environment variable or standard input.
For example, running 'MyApp --setup' would then prompt like this:
Save secure config to (/opt/etc/myapp/.config/secure.conf):config/secure.conf Config Permissions (defaults to rwx------): rwxrw---- Add config path in the form <key>=<value> (leave blank when finished):myapp.secure.password=hi Add config path in the form <key>=<value> (leave blank when finished):myapp.another.config.entry=123 Add config path in the form <key>=<value> (leave blank when finished): Config Password:password
Then, running 'MyApp --secure=config/secure.conf -myapp.whocares=visible -show=myapp'
would prompt for the password from standard input, then produce the following, hiding the values which were present in the secure config:
NOTE: even though the summary obscures the values, they ARE present as PLAIN TEXT STRINGS in the configuration, so take care in limiting the scope of where the configuration is used, either by filtering back out those values, otherwise separating the secure config from the remaining config, or just ensuring to limit the scope of the config itself.