The result of running this application
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 secret config file if it exists. e.g., try running the app without the secret config.
the command-line argument to specify the path to an encrypted secret config file (e.g. MyApp -secret=.passwords.conf)
the flag which should indicate that we should prompt to setup secret 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
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 'secret' 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 secret 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 -secret=<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
a function to read in the user input
the argument to check for in order to run the secret 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 secret password config> (e.g. defaults to "--secret", as in --secret=/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 secret config parse result should the application need to do something with it
the result of the secret config user arguments
the total configuration, potentially including the secret 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 '--secret=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 secret config to (/opt/etc/myapp/.config/secret.conf):config/secret.conf Config Permissions (defaults to rwx------): rwxrw---- Add config path in the form <key>=<value> (leave blank when finished):myapp.secret.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 --secret=config/secret.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 secret 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 secret config from the remaining config, or just ensuring to limit the scope of the config itself.