On Sun, Sep 25, 2011 at 5:43 PM, Michal Wojciechowski <odyniec@odyniec.eu.org> wrote:
On 09/22/2011 11:35 PM, Assaf Gordon wrote:

Somewhat related to the "sensitive" config data in SCM" topic discussed recently,
I would like to suggest the followng small patch to "Dancer::Plugin::Database" :

Instead of specifying "username/password" in your yml config file, I've added a new setting called "credentials".
This one points to a simple text file that would contain the user name and password.

With this one can checkin all the configuration files, never worrying about passwords.

I don't think that's a such a good idea. There are many other sensitive configuration parameters that could be in the configuration file, like secret API keys, password salts, even e-mail addresses. Following this idea, we'd have to create a separate file for each one of them.

I think the de facto standard of what to do with configuration files in version control systems is to create an "-example" version of the file (e.g. config-example.yml) and store that in the repository, instead of the actual configuration file. The example file has all the default settings, and placeholders for sensitive information, such as "password: YOUR_PASSWORD". Most web applications use this method, or a similar one.

This also has one "psychological" (so to speak) benefit, as it requires the user to go through the configuration settings and actually configure the application before using it.

Anyway, if this idea gets implemented, please don't make it the default :)

--
Michal Wojciechowski
http://odyniec.net/ | http://search.cpan.org/~odyniec/


_______________________________________________
Dancer-users mailing list
Dancer-users@perldancer.org
http://www.backup-manager.org/cgi-bin/listinfo/dancer-users

I don't think this is a particularly good idea either, ... and there are other better ways to handle this. Besides the de facto standard Michal spoke of which I can vouch for, most web devs completely ignore the abilities and benefits of having database e.g. create limited user accounts. You can simply create a restricted user account that only has permission to do what you allow other developers to do and then the user's credentials are no longer that big of a secret, ... then, when its time to go live, ... use a different db user. 

Ship an additional .sql file with the app in the SCM that creates this user locally for your other developers. Now everyones environment is exactly the same minus the OS, etc.

-- 
Al Newkirk
ANAIO