Following up on a bug, I found out that our current handling of strong_parameters is seriously flawed. Currently, if a request parameter is filtered out, there is no indication that it happened (except in the log only in production). This causes three significant issues:
- Users using the API who mistype a parameter name or mistakenly pass a value of the wrong type (e.g. integer when array was expected) assume their command was successful, when in fact, the parameter was filtered out completely leading to unexpected results which are hard to debug (no indication of the wrong parameter other than an easily missed message in the log)
- Developers wasting hours and days attempting to debug issues without realizing that a parameter they were expecting was filtered out with no indication at all, since in development environment we don’t even log filtered parameters. Based on True Story™.
- Tests passing when they should have failed since some of the parameters were filtered and not applied.
To mitigate this, I have started working on changing this behavior to raise an error when a parameter is filtered, and present a user-friendly message indicating what went wrong:
While this is still WIP, this has caused many (547) tests to fail - some of them which should have failed already, others due to various request params that are being passed in but not permitted. I will continue fixing all our tests to handle this.
However, once this is merged in core, all plugins may need to make some other changes as well. Plugin maintainers might be able to proactively fix their tests or filters by setting
config.action_controller.action_on_unpermitted_parameters = :raise and seeing what requests break.
At this time, we sadly don’t have the possibility of indicating whether the failure was caused by bad name or value due to the way ActionController does the filtering. This might be possible to handle in core in a follow-up PR in the future, or by changing it in Rails.