No; Django does that, and the result is that people check that random secret into source control. The correct solution is to not have the secret in code at all, but to read it at initialization time out of some kind of secrets management system (traditionally via environment variables). Unfortunately, frameworks generally can't do this in a hosting-setup-agnostic way; you have to understand the specific facilities that your PaaS or deployment system offers for this, and some (looking at you, Google App Engine Standard Environment) don't offer adequate ones.

I am not saying the secret should be in the code itself.

The app generator could generate a .gitignore including another dotfile with the secret in it. Or print a message on how important it is to configure the secret properly.

My point was that a framework should not generate a working value that is insecure. And if generating no value and have the app not start without additional configuration is the best way, this should be the way to go.

I THOUGHT Django generated a random secret! What's MF on about?

ah I can see how that sidebar is confusing now. the point was just to highlight the configuration names across different frameworks. as @ameliaquining points out, a randomly generated secret that's been leaked to github has much the same effect as one that is easily guessed.

I'll think about ways to make it more clear! Thanks

I think the purpose of that sidebar is to list the names of relevant configuration keys for some frameworks. Pretty confusing though.

I guess his point is that you /could/ set this to a weak key if you want, but I can't think why you ever would

Or, for simple cases where a single server handles all clients (i.e. no load-balanced cloud setup), just generate it on startup. A server restart will invalidate sessions, but oh well.