PoC & Documentation for new Parameters#mandate

[martinemde]

Motivation / Background

I've been hunting around trying to fix the problem with the default, recommended way of handling parameters in Rails.

user_params = params.require(:user).permit(:name, :age)

This is fine until someone using your app starts messing with the parameters and causing 500 errors by passing:

/path?user=string

This causes a NoMethodError because permit is called on "string".

The recommendation is not the best way. Instead, the first statement should be written like this:

user_params = params.permit(user: [:name, :age]).require(:user)

However, because this is a bit messy and repetitive and the order almost seems backwards, I suggest adding a new method to params that does this all in one go and ensures that it's more likely people do it correctly.

params = ActionController::Parameters.new(user: { name: "Martin", age: 40 })
permitted = params.mandate(user: %i[name age])
permitted.permitted?   # => true
permitted.has_key?(:name) # => true
permitted.has_key?(:age) # => true

The name is a little weird at first, and I'm open to changing it. My thinking is that a "mandate" is something that is "officially required" (something that is both permitted and required). This speaks to the actual code, which is basically just permit(args).require(args) with some extra behavior for hashes to require the keys.

Detail

This pull request adds the mandate method documentation only. Please tell me if it is worth writing the tests. Forgive my hesitance, but given that many of my other recent PRs have not received any comments, I don't want to spend a bunch of time writing tests for a dead-end feature. I hope you'll understand.

Additional information

Related PRs and issues that address this problem:

• Potentially fixes Strong Params require with permit combination produce unexpected exception #42953 without changing existing behavior.
• Improve requiring of scalar parameters #44297 triggered me to dig into this more, where I arrived at this solution.

Checklist

Before submitting the PR make sure the following are checked:

• This Pull Request is related to one change. Unrelated changes should be opened in separate PRs.
• Commit message has a detailed description of what changed and why. If this PR fixes a related issue include it in the commit message. Ex: [Fix #issue-number]
• Tests are added or updated if you fix a bug or add a feature.
• CHANGELOG files are updated for the changed libraries if there is a behavior change or additional feature. Minor bug fixes and documentation changes should not be included.