Yep, that's an exploit waiting to happen.
Another option. I was thinking of putting the secret key in a separate
file and not checking it into source control. Have
config/environment.rb load that file, or create it if necessary. So
if you're just checking out the sources, you get a different key from
everyone else. For deployment, symlink to a share directory, say
somewhere in /etc.
> - Trevor
I think the correct fix here is to notify the projects concerned and
tell them what they need to do. Assaf's suggestion of reading from a
file is probably the best bet for them.
I'm assuming these projects don't ship with a database.yml file
including a password, this is basically the same thing.
We use a task called setup. Once you get the source code, there are
still a few things you need to do before you're up and running:
installing gems, creating dev/test database, populating dev database,
etc. So the first step is running rake setup, and that could take
care of generating a secret key for you. The rest will be taken care
of by .gitignore.
> Perhaps this file could be more generic as well, kind of a designated
> place to put all secret keys/passwords.
I hope so, that way we can have generic tasks that work across apps.
One I'm thinking of is setting a secret key on the server and linking
to it during deployment. You probably don't want to use the same key
in development and production. I only need to distract you for a
minute, peek at your machine to find out your site's secret. So this
applies also to closed-source apps.
If we generate the file when we create the application, people are
going to add it to source control just like they do environment.rb. I
really don't think we need to change what rails does here, the
applications simply need to have:
:secret=>File.read(File.join(RAILS_ROOT, "config", "secret.txt"))
> On Aug 7, 1:49 am, Hongli Lai <hongli...@gmail.com> wrote:
>> On Aug 7, 9:54 am, "Michael Koziarski" <mich...@koziarski.com> wrote:
>> > I think the correct fix here is to notify the projects concerned and
>> > tell them what they need to do. Assaf's suggestion of reading from a
>> > file is probably the best bet for them.
>> Yes, agreed. But maybe it would be a good idea to store the secret key
>> in an external file. If the key file doesn't exist, then a new key
>> file is generated. The developer can then choose whether or not to
>> include the key in the repository. This would save open source app
>> developers a little bit of hassle.
>> I can only imagine one thing going wrong: people deploying the app
>> over multiple web servers while forgetting to copy the key file too.
>> If this happens then each web server will have a different secret key,
>> and this will break a user's session if he's load balanced to a
>> different web server.