Not a Dancer question per se, but I am sure a few of you have encountered this, and it is a "best practice" issue I am encountering for my Dancer apps, so -- I have hard at work learning Git, striving to put all my work in a Git repo (including Github, where appropriate). Yesterday I realized that I would be committing my database and other passwords to the repo as well (I am using the most excellent Dancer::Plugin::Database). A little bit of searching brought me to the conclusion that I had to implement some kind of "smudge" and "clean" filters using .gitattributes -- so when I commit my work to the repo, the sensitive info would get replaced by **** (or other placeholders), and when I would checkout the work, the placeholders would get replaced by the real info. Before I waste too much time learning and implementing these smudge and clean filters, it would behoove me to ask if one of you already has those in place, and if you would kindly share them with me and the community... appropriately via Github. Many thanks in advance, Puneet.
On Thursday 08 September 2011 17:42:18 Mr. Puneet Kishor wrote:
Not a Dancer question per se, but I am sure a few of you have encountered this, and it is a "best practice" issue I am encountering for my Dancer apps, so --
I have hard at work learning Git, striving to put all my work in a Git repo (including Github, where appropriate). Yesterday I realized that I would be committing my database and other passwords to the repo as well
I would be inclined to simply put the database config into environments/production.yml, and *not* commit that file. So, non-sensitive app config goes in config.yml, but the sensitive stuff is not included. (You'll probably, at some point, want to have differing database config for development and production anyway...)
(I am using the most excellent Dancer::Plugin::Database).
Thanks - always good to hear of happy users :)
A little bit of searching brought me to the conclusion that I had to implement some kind of "smudge" and "clean" filters using .gitattributes -- so when I commit my work to the repo, the sensitive info would get replaced by **** (or other placeholders), and when I would checkout the work, the placeholders would get replaced by the real info.
Hmm, that sounds interesting! If you do take that option, I'd be interested to see what you come up with! Cheers Dave P -- David Precious <davidp@preshweb.co.uk> (bigpresh) http://www.preshweb.co.uk/ "Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz)
On Sep 8, 2011, at 1:02 PM, David Precious wrote:
On Thursday 08 September 2011 17:42:18 Mr. Puneet Kishor wrote:
Not a Dancer question per se, but I am sure a few of you have encountered this, and it is a "best practice" issue I am encountering for my Dancer apps, so --
I have hard at work learning Git, striving to put all my work in a Git repo (including Github, where appropriate). Yesterday I realized that I would be committing my database and other passwords to the repo as well
I would be inclined to simply put the database config into environments/production.yml, and *not* commit that file.
So, non-sensitive app config goes in config.yml, but the sensitive stuff is not included.
(You'll probably, at some point, want to have differing database config for development and production anyway...)
Well, that is not a good option, because that way other users who clone the repo don't get everything to make the project work. They will need to perform a separate step to recreate production.yml.
(I am using the most excellent Dancer::Plugin::Database).
Thanks - always good to hear of happy users :)
A little bit of searching brought me to the conclusion that I had to implement some kind of "smudge" and "clean" filters using .gitattributes -- so when I commit my work to the repo, the sensitive info would get replaced by **** (or other placeholders), and when I would checkout the work, the placeholders would get replaced by the real info.
Hmm, that sounds interesting!
If you do take that option, I'd be interested to see what you come up with!
Well, I do want to implement it, but am struggling with it. I was thinking of a simple script like so #!/usr/bin/env perl my %vars = ( driver => 'Pg', database => 'dbname', host => 'host', port => 5432, username => 'dbusername', password => 'dbpassword' ); my $template = qq{ plugins: Database: driver: '[% driver %]' database: '[% database %]' host: '[% host %]' port: [% port %] username: '[% username %]' password: '[% password %]' #connection_check_threshold: 10 dbi_params: RaiseError: 1 AutoCommit: 1 #on_connect_do: ["SET NAMES 'utf8'", "SET CHARACTER SET 'utf8'" ] #log_queries: 1 }; $template =~ s/\[% (.*?) %\]/exists $vars{$1} ? $vars{$1} : ''/ge; and the reverse of that on the way in.
On Friday 09 September 2011 00:07:51 Mr. Puneet Kishor wrote:
On Sep 8, 2011, at 1:02 PM, David Precious wrote:
I would be inclined to simply put the database config into environments/production.yml, and not commit that file.
So, non-sensitive app config goes in config.yml, but the sensitive stuff is not included.
Well, that is not a good option, because that way other users who clone the repo don't get everything to make the project work. They will need to perform a separate step to recreate production.yml.
Well, they're presumably going to have to set up a database, then put the appropriate connection details into the config file, no? -- David Precious ("bigpresh") http://www.preshweb.co.uk/ "Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz)
On Sep 8, 2011, at 6:10 PM, David Precious wrote:
On Friday 09 September 2011 00:07:51 Mr. Puneet Kishor wrote:
On Sep 8, 2011, at 1:02 PM, David Precious wrote:
I would be inclined to simply put the database config into environments/production.yml, and not commit that file.
So, non-sensitive app config goes in config.yml, but the sensitive stuff is not included.
Well, that is not a good option, because that way other users who clone the repo don't get everything to make the project work. They will need to perform a separate step to recreate production.yml.
Well, they're presumably going to have to set up a database, then put the appropriate connection details into the config file, no?
indeed, but the config file may be fairly complex (containing not just the db -- the sensitive -- params but also various other params). Giving the entire YMLs, for both environments, would be a complete repo. Puneet.
On Thu, Sep 8, 2011 at 4:13 PM, Mr. Puneet Kishor <punk.kish@gmail.com>wrote:
On Sep 8, 2011, at 6:10 PM, David Precious wrote:
On Friday 09 September 2011 00:07:51 Mr. Puneet Kishor wrote:
On Sep 8, 2011, at 1:02 PM, David Precious wrote:
I would be inclined to simply put the database config into environments/production.yml, and not commit that file.
So, non-sensitive app config goes in config.yml, but the sensitive stuff is not included.
Well, that is not a good option, because that way other users who clone the repo don't get everything to make the project work. They will need to perform a separate step to recreate production.yml.
Well, they're presumably going to have to set up a database, then put the appropriate connection details into the config file, no?
indeed, but the config file may be fairly complex (containing not just the db -- the sensitive -- params but also various other params). Giving the entire YMLs, for both environments, would be a complete repo.
I've done it like this in the past... ship a file called production.yml-default which contains all the keys and dummy values for the sensitive stuff. As part of the instructions they rename it to remove the -default part of the filename. They fill out their stuff. There's svn:ignore it git:ignore that ignores the "real" .yml file so you don't have to worry about it getting checked in.
Puneet.
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
participants (3)
-
Brian E. Lozier -
David Precious -
Mr. Puneet Kishor