[steveklabnik]

We've had discussions about this several times, and haven't come up with something that's satisfactory as a generic replacement, other than "configuration could probably be improved."

For one example, see this from a year ago: https://github.com/rails/rails/pull/3777#issuecomment-289375...

> If we ignore them, this means a recently created, pushed and then cloned project is not going to work at all.

Some people replace it with a new file upon deployment, some people use ENV vars, some (most) people never open-source their app, and don't mind employees seeing it...

I personally do https://github.com/hotsh/rstat.us/blob/master/config/initial...

Being generic is hard.

[danielfone]

I absolutely agree that there's no easy solution to this (or it would've been "fixed" already).

> some (most) people never open-source their app, and don't mind employees seeing it...

One of my concerns is that people believe it's only a risk if they ever open source their application. While most apps don't have to worry about a motivated attacker in reality, the risk isn't simply secure or unsecure.

It's more a case of 'more difficult' vs. 'much easier' to compromise. I fear many engineers don't think of securing their apps like this. I know I've only recently begun to understand this way of thinking about security and it's changed the way I code.

[potomak]

See also comments on HN[1] about an "old" post[2] from Hongli Lai (Phusion) about this topic.

[1] https://news.ycombinator.com/item?id=5007530

[2] http://blog.phusion.nl/2013/01/04/securing-the-rails-session...

[olalonde]

Have you considered generating a key at first startup and storing it in a database? Or would that introduce too much unnecessary overhead while introducing an attack vector through the database?

[rst]

The extra overhead could be kept pretty small. After being retrieved once, it can be cached in the memory of a server process. So, there's one short SQL query at process startup (or perhaps first request, depending on how you do it), and negligible overhead after that.

[joevandyk]

This is what I do, works great.

Most of my application secrets/configuration/keys/tokens are stored in the database.

The only one that's not is the information about how to connect to the database. That's stored in the DATABASE_URL environment variable and it's stored on each machine. envdir is used to start the apps, reading that environment data.

[hayksaakian]

This seems reasonable, why not do it that way?

To a newbie like me, everything will "just work" in development. In production, I'll get a pretty explicit/precise error message.