You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The implementation of RequestBodyParamConverter seems so "naive", hope that is my bad configuration or something. It works fine when you don't provide entity identifiers in the body payload, but is potentially dangerous when you do.
Consider this scenario: a POST request to /api/products in order to create a new entity:
In this scenario, the converter deserialized the provided payload. In turn, the JMS serializer would retrive the existing record with the given id, and merge the name property. Without any futher control, you end up updating the resource instead of creating a new one!
Even worst example: a PUT to /products/1 request with { "id": 2, "name": "Foo Bar" } as payload, which is supposed to replace the resource at the id 1. In this case it would end up updating the wrong resource!
The implementation of
RequestBodyParamConverter
seems so "naive", hope that is my bad configuration or something. It works fine when you don't provide entity identifiers in the body payload, but is potentially dangerous when you do.Consider this scenario: a
POST
request to/api/products
in order to create a new entity:In this scenario, the converter deserialized the provided payload. In turn, the JMS serializer would retrive the existing record with the given
id
, and merge thename
property. Without any futher control, you end up updating the resource instead of creating a new one!Even worst example: a
PUT
to/products/1
request with{ "id": 2, "name": "Foo Bar" }
as payload, which is supposed to replace the resource at the id1
. In this case it would end up updating the wrong resource!This is an example controller action:
The text was updated successfully, but these errors were encountered: