Strong Params requires you to enumerate all params on the server. But why couldn't you know what are valid params while building your form? You could serialize the params shape in the form builder and include it in your post payload, signed by the app secret to avoid tampering.
It should have done this from the beginning!
It would probably be not too hard to do as a gem - you inject a hidden field when form_with is called and you define a new method on params so the controller can indicate that this approach is being used.
I can see how you could generate the Extract step of an ETL process (i.e. a validation specification) purely from the form HTML itself. But I'm not sure where you'd stuff the information required to do the Transform or Load steps. It isn't cleanly separable into per-component data attributes.
If I know, for instance, an admin is identified by an `is_admin` flag, I could add this to the allowed params and send my flag. Bam. I’m now an admin.
I know the example is a bit simplistic, but it wouldn’t take long to comb your app for a real world example where this would be problematic.
I’m not super keen myself as I prefer the implementation to be much more explicit than magic, but there doesn’t seem to be an obvious security hole here.
Strong Params is a canonical violation of DRY. When you build your form, you fill it with fields that are allowed to be filled out and submitted. Then you have to duplicate that work in the controller for no obvious benefit.
As for "more explicit than magic" I prefer to think of this as "automatic" or "conventional" rather than magic. Much of Rails' "magic" is this exact kind of thing, allowing the right thing to automatically happen with the ability to step in or override manually when the convention isn't what you want.
I get why you'd want it to be more explicit. I think that this feature was invented to solve a security problem and the solution was to give devs more work to do. There's no obvious reason why it couldn't be automatically taken care of for the dev and it would definitely make maintenance and legacy app upgrades smoother.
Besides, you still have to validate the signature server-side, so it's not like it's saving any work. Validation just gets split up between generating the signature, a network round-trip, and validating the signature.
The "work" the GP is trying to save here isn't CPU cycles, but rather developer labor — the redundant labor of writing both a form view that describes form inputs, and a form-value schema validator to be called from the controller that receives the form's submitted input values.
Generating the signature, and validating the signature, would both be done transparently by middleware components of the framework, with no marginal developer labor required per form.