Unpermitted strong parameter lost in logs

A May Of WTFs
1

It often happens to me that I forget to whitelist a newly introduced strong param in the controller. I then have a hard time figuring out what’s wrong with the app. Eventually I find the cause, but the way to find it could be easier (especially for beginners).

Idea for improvement of the situation: How about raising an error for incoming but unpermitted parameters in the development environment?

# config/environments/development.rb

config.raise_on_unpermitted_params = true
7 Likes
2

This happens to me too!

It sounds like you’re saying that we should leverage the existing configuration option here by making it a default for new Rails projects. Does that sound accurate?

3

It sounds like you’re saying that we should leverage the existing configuration option here by making it a default for new Rails projects. Does that sound accurate?

I think this is a great idea! I try to enable this on every new Rails app I create

4

I would also back this.

It’s similar with the issue of assets breaking in production but not in development, and a welcome improvement on developer experience.

5

It’s my default in development env :slight_smile:

6

This is a great idea. I’ve lost track of how many minutes I’ve spent over 10 years binding.pry to understand what was going on until I noticed I hadn’t properly permitted params.

This should be added to the default config/environments/development.rb

config.raise_on_unpermitted_params = true
7

Looks like there’s a lot of support for this.

Does anyone want to step up as a champion for making this a Rails default?

That would look like:

  1. Opening an issue on the Rails Github asking about this. This issue should frame the problem as clearly as possible. It should also make it clear that you’re willing to do the work of making this change happen.
  2. Assuming there’s positive feedback from the Rails maintainers on your issue, write a PR (or collaborate with someone on it). Work with the maintainers to get it shipped.

Some concerns I can see them having:

  • What does the change path would look like for old projects that haven’t manually set this as a default?

If the issue opened can talk about e.g. how to effectively warn users about the behavior change, possibly by phasing this over multiple Rails versions, that will help the maintainers visualize a world in which this change can be made safely.

1 Like
8

If I understand it correctly Rails already has such a configuration:

config.action_controlller.action_on_unpermitted_parameters = ...

What might be happening is that in development it defaults to log, and maybe it should default to raise instead.

1 Like
9

@lfv89, that’s correct. As per Action Controller Parameters:

The default value is :log

I’d love this change too. We made this standard with our Rails Application Template:

insert_into_file 'config/environments/development.rb', <<-CONFIG, before: /^end/

  config.action_controller.action_on_unpermitted_parameters = :raise
  ...
CONFIG

I see no concerns for old apps for two reasons:

  1. If raising in development (and test) breaks existing apps, it has served its purpose of exposing an unnoticed problem. I don’t recommend :raise in production.
  2. When old apps upgrade Rails, they’d have an opportunity to reject this change after applying rails app:update. They also have the opportunity to keep config.load_defaults = 6.0 and apply new configs as they’re ready via config/intializers/new_framework_defaults.rb. See Configuring Rails Applications and Upgrading Ruby on Rails. This is a great mechanism for easing into new configs, and it is already there.
3 Likes