Re: Best way to include a passwords file in a project?

[Manuel Paccagnella]

I'm not sure that a password file is an optimal solution for this problem. Maybe the 12 factors, and in particular the config one, could give you some ideas.

Personally I think that credentials are environment-specific, not application-specific. So I'd place them in an external storage service (like a DB). Or, to make things simple, put them in a file somewhere in the system and load it through an environment variable (see 12 factors, III).

This is as simple as writing:

(load-passwords-from-file (System/getenv "PASSWORD_FILE"))

Hope it helps :)

Il giorno martedì 18 dicembre 2012 03:21:31 UTC+1, Marco Munizaga ha scritto:

I'm currently doing something like src/project/passwords.clj and git ignoring that, does anyone have a better solution? maybe a way to place the passwords.clj alongside project.clj in the root directory? Would this be possible through leiningen profiles?

Thanks

[Alex Baranosky]

I don't like the environment variable approach because of the dependency on global state makes deploying harder.

I'd usually have a config file like config.clj whose contents were just a Clojure map.  When loading the application I'd pass in the location of the config file as a parameter, and read-string the file at run-time.  That said, it can sometimes be convenient for development to have some default config file location, so you don't always need to pass the config location in.

Alex

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

[Wei Hsu]

I second Manuel's environment variable approach. On heroku this is easy to set with

heroku config:add PASSWORD_FILE="/etc/passwords"

For more complex deployments, you can use automation systems like Pallet or Chef to manage environment variables.

[Sean Grove]

Hey Alex, I accidentally hit a button to subscribe you a mailing list while reading this thread, please ignore it. Sorry about that!

[Manuel Paccagnella]

Il giorno mercoledì 19 dicembre 2012 22:40:18 UTC+1, Alex Baranosky ha scritto:

I don't like the environment variable approach because of the dependency on global state makes deploying harder.

 

I'd usually have a config file like config.clj whose contents were just a Clojure map.  When loading the application I'd pass in the location of the config file as a parameter, and read-string the file at run-time.  That said, it can sometimes be convenient for development to have some default config file location, so you don't always need to pass the config location in.

This is a good idea, but I don't see how this approach is different from the environment variables one. You simply pass the configuration file path directly instead that through an environment variable.

A generic application needs several configurations, and here we have two different approaches:

a) Write them in a config.clj file and pass that file location when app is started
b) Set some environment variables and let the app get by itself the parameters that it needs from it
 
Both are valid approaches IMHO. Maybe (a) has the advantage that you can write sample config.clj file and pass them around, but other than that I don't see any difference on ease of deployment.