Is it possible to load application.secret from somewhere besides conf/application.conf?
In my project, I already have an encrypted file where application secrets and whatnot are stored. Can I just store application.secret in there, or must it be in conf/application.conf?
why do you encrypt that file? and how/when does it get decrypted?
normally you should think about where to store critical data like credentials and the application secret. in my opinion, it is not recommended to store it in a file that gets committed via some type of repository, even when it is encrypted. a better solution on "how to deal with config-vars" could be to store variable/critical config-data in sys/env-variables, like explained here http://12factor.net/config
and then, you could access these env-vars in your java-code via your definitions in your application.conf like explained here https://commons.apache.org/proper/commons-configuration/userguide/howto_basicfeatures.html
for example in your application.conf:
%prod.db.connection.password=${env:db.connection.password}
for more on that read http://www.ninjaframework.org/documentation/configuration_and_modes.html
does this answer/clear your question?!
No, it does not. I mean, I understand what you're trying to tell me, but it doesn't solve the problem I actually have.
why do you encrypt that file? and how/when does it get decrypted?
so what is the reason for encrypt that file?
well, for me it looks like you want your "application.secret" to remain private in terms of "nobody else could see it in your github-repo"? if so, then a great alternative to github is bitbucket which offer free private repositories.
take care, that your solution with "git-crypt" should also be supported by the service (e. g. heroku) you finally want to run your app on. the preferred method of keeping passwords/api keys secret on heroku is to set config values via the heroku commandline application.
Our project is open source so we can take advantage of free Travis support.
I was successfully able to get git-crypt to work with Travis. The application itself needs the API keys, but so do we while developing on our machines. The encryption process is transparent; anyone who clones our repo will see an encrypted file, but the four of us working on the project can just read and edit it in plain text and be none the wiser.
If such a case is really important where application.secret has to be loaded from somewhere else, a secret loading interfaces can be introduced with default implementation that reads application secret from conf/application.conf. Then clients can bind their custom implementations to load secrets from other sources.
I do not exactly know how git-crypt works but this is my opinion on how to solve such an issue in a generic way. Can work on that if that would be a useful feature for the framework.
I know we could use something like this in our own apps. For us it would include both secrets and non-secrets though. Ideally, there'd be a way to inject/supply generic config data before the ninja app starts up. I guess the pattern could be something like: jvm starts, load ninja properties, allow new config to be overlayed on top of those ninja properties, start ninja app with the overlayed version.
The downside to the pattern i suggested is that you wouldn't have guice yet, other ninja modules, etc. It'd be very isolated from the rest of ninja.
On Thu, Jan 12, 2017 at 7:34 AM, Azilet Beishenaliev < [email protected]> wrote:
If such a case is really important where application.secret has to be loaded from somewhere else, a secret loading interfaces can be introduced with default implementation that reads application secret from conf/application.conf. Then clients can bind their custom implementations to load secrets from other sources.
I do not exactly know how git-crypt works but this is my opinion on how to solve such an issue in a generic way. Can work on that if that would be a useful feature for the framework.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ninjaframework/ninja/issues/506#issuecomment-272152385, or mute the thread https://github.com/notifications/unsubscribe-auth/AAjwAiMCPYgOzwT2EgMVG5_wXXfABAIDks5rRh3bgaJpZM4IYZpb .