Why does #Symfony define what appears to be a “real” value for APP_SECRET in the .env file that’s committed to your repository, and then, right above it, there’s a comment that says (in all caps):
“DO NOT DEFINE PRODUCTION SECRETS IN THIS FILE NOR IN ANY OTHER COMMITTED FILES.”
Where’s the documentation that explains what APP_SECRET is used for? Why doesn't it put this value in .env.local (ignored by .gitignore)?
@ramsey If I recall correctly, don't quote me on this, that the APP_SECRET Is also used for 'remember me' tokens. So if it leaks, you can get into any account.
Which yeah.. It needs to be in .env.local instead at the very least.
@pieceofthepie I haven’t found anything that explains what APP_SECRET is used for, nor have I found any docs that say it needs to be regenerated for production
@manal@nicolasgrekas I think that should be explained in a comment in the .env file (or at least linked to from there). I have no idea how the value is used, so I assumed it was a “dummy” value. I was planning to push this code as a public repo, but I guess it’s not wise to leave that value in there?
@ramsey@manal@nicolasgrekas well it's not sensible if it's used only locally, and then you use a .env.prod or (better) inject a real env variable in your prod environment.
@jaapio I’ve been looking into this more, and I’m not sure what you mean by “it’s not a glue between symfony and existing middleware.” That’s exactly what it looks like, to me.
It allows you to use anything that implements Psr\Http\Server\MiddlewareInterface as middleware in Symfony, so any existing middleware should work.
@tobiaskoengeter@Crell@ramsey My brief experience with Symfony was that Symfony likes defining routes and actions in a YAML file, which means of course I have no editor support and can't just go-to-definition of anything, having to always search for things manually. Horrible user experience.
@tobiaskoengeter@ramsey The entire "commit your .env to use for some app settings, but also have a .env.actual-env that you don't commit that has env-sensitive stuff" is completely broken.
The whole point of a .env is to hold env-specific, non-committed stuff. If it should be consistent between instances, it should be in a config file, NOT an .env.
If you're committing .env to Git, you're wrong. End of story. Symfony wants you to do so. Thus Symfony is wrong.
@Crell@ramsey I understand your point! I think there are several things mixed up in the .env: on the one hand, it is a kind of template that only describes what should be defined in the environment. The file could therefore also be called .env.boilerplate or .env.example. On the other hand, it also contains real information and is therefore not a template - which actually makes it inconsistent.
@Crell@ramsey Even though I hate to say it, Laravel's logic is a little better here: during installation, the .env.example is taken as the basis and copied as .env.
Add comment