Berg and Cruz demonstrate how to change abitrary fields of an entity that is injected in a controller mapping like so:
@PostMapping("/person")
public String updatePerson(Person person) { ... }
In this example every POST parameter that matches something like person.foo will be resolved to a SettersetFoo - no matter if foo was part of the form being posted or not. Thus, any field may be changed through a POST. To circumvent this problem, the entities should not be injected but loaded on demand. Instead, a form class which represents the HTML form should be posted and converted to the matching entity afterwards.
However, the issue as described above does not affect us directly as we are already not posting the entities themselves, but the respective form. Nevertheless we frequently utilize a pattern like the following:
@PostMapping("/persons/{id}")
public String updatePerson(@PathVariable("id") Person thePerson,
@ModelAttribute("form") UpdatePersonForm form) {
...
}
We have to be sure that in this case the person is not modified through POST data but indeed only retrieved from database.
Berg and Cruz demonstrate how to change abitrary fields of an entity that is injected in a controller mapping like so:
In this example every POST parameter that matches something like
person.foo
will be resolved to a SettersetFoo
- no matter iffoo
was part of the form being posted or not. Thus, any field may be changed through a POST. To circumvent this problem, the entities should not be injected but loaded on demand. Instead, a form class which represents the HTML form should be posted and converted to the matching entity afterwards.However, the issue as described above does not affect us directly as we are already not posting the entities themselves, but the respective form. Nevertheless we frequently utilize a pattern like the following:
We have to be sure that in this case the person is not modified through POST data but indeed only retrieved from database.