new framework defaults should be in the environment, not an initializer

[jjb]

Because new_framework_defaults is in an initializer, it overwrites any settings in the environment files. The result is that changing a setting in an environment file might have no effect. I think this is bad because

1. it is confusing for someone who doesn't realize that the setting is configured in new_framework_defaults. (this just happened to me)
2. conceptually it seems more appropriate to put the future framework defaults "between" the current framework and the app's configuration. This way
   • they are truly setting what the application environment config experiences as a default
   • if the new_framework_defaults are never modified, the app environment config can be seamlessly carried from the current framework version to the next one and have the same meaning. with the initializer approach, when moving to the next framework version those settings will have to either be moved into environment files or into other initializer files. (if they are moved into new_framework_defaults on the new app, which now also has new new framework defaults, then the file will be a mess that doesn't actually reflect the defaults of the current and future version).

Backing up a little: The way it is now, new_framework_defaults is simply just one more, final config file that happens to have things related to the future framework. since all these settings can be changed by the user, and a user typically changes such settings in the environment config, maybe instead of having a standalone initializer it should just be dumped into application.rb with comments about what the values are for present and future rails versions. Then the user can modify it as needed and the config will be portable to the next version.

[rafaelfranca]

I'm not sure about this. We don't want to pollute the application.rb and environment files with a lot of configurations that are automatically generated by the framework.

Did you had this problem you described with a new application or upgrading an existent application?

[jjb]

We don't want to pollute the application.rb and environment files with a lot of configurations that are automatically generated by the framework

true, but isn't it sort of the same thing? the same type of configuration, just sitting in a different place?

Did you had this problem you described with a new application or upgrading an existent application?

A new application. After deploying, I discovered that hsts was by default telling my users to require https for all subdomains, which I didn't want. I quickly found the setting and put it into my environment file, but nothing I did had any effect. On a whim someone on the team searched our codebase for "hsts" and found the framework default, which had been overwriting my environment file.

[rafaelfranca]

true, but isn't it sort of the same thing? the same type of configuration, just sitting in a different place?

yes, a different place that we are fine to pollute.

I'm afraid there is nothing we can do here. This could happen with any Rails configuration that is now in config/initializers not only in the new_framework_defaults file. And since we believe initializers are a good place to configurations, there is no point on moving them.

[jjb]

well, in the spirit of my main point...

it seems more appropriate to put the future framework defaults "between" the current framework and the app's configuration.

then these should go before environment AND initializers

but anyway, if you haven't heard lots of other users complain because they were confused about such a setting lurking in the initializer, then it's probably not a big problem. it caused me hours of downtime for some of my services so i'm focused on my use case :)

[jarthod]

Hello, I'm having the same trouble now on Rails 5.1.
The new_framework_defaults.rb file is gone and there's no single line mentioning ssl_config in my project.
I tried adding in my production.rb:

  config.force_ssl = true
  config.ssl_config = { hsts: { subdomains: false } }

But the setting is not taken into account and I still have the includeSubDomains flag.
How are we supposed to configure this?

---

Ok my bad 🤦‍♂️ I used ssl_config instead of ssl_options, sorry about that…