spencergibb
commented
2 years ago There's an existing issue about validation during this process. (Ok mobile, will need to find). There are two pieces, the spring environment, which doesn't have any form of validation and configuration priorities, which can have validation. But config props need values in the spring environment before they can be validated. There would have to be a new process to validate config props on a separate environment before it gets applied or be able to roll back, none of which exist.
Copied from https://github.com/spring-projects/spring-framework/issues/27962 as suggested by https://github.com/bclozel.
In our project, we are using Spring Boot Actuator (version 2.6.2) as well as Spring Cloud (2021.0.0) on Spring Boot Version 2.6.2.
My current objective is to implement a config editor, which enables the users of our product to manipulate our custom spring properties (properties in classes with @ConfigurationProperties) during runtime.
I'm currently somehow achieving this goal using a combined approach. This approach consists of sending a POST request to the /actuator/env endpoint (that's why Spring Cloud is a dependency of our project) with a valid HTTP request body as well as writing to an external application.yaml file, which stores these config overrides, in case the spring container has to restart (as all calls to /actuator/env only manipulate the Spring environment).
Lets say I have this configuraiton bean:
When I make a HTTP POST request to /actuator/env, my request body looks like the following:
This works fine as long the the value in the value property matches the type of the property, which is defined in the configuration bean. But let's say, the type of the property custom.my-property is of type int (or any other type), like this:
When I now send my HTTP POST request with value = "Hello World", the problems (and potential bugs or things to improve) arise.
The /actuator/env endpoint seems to not make any validation of the request body. It looks like it changes the spring environment, but then spring cannot bind the new value to the configuration bean (ovioulsy, because a string cannot be bound to an integer). An exception occurs, and the response of the /actuatur/env endpoint contains the following:
You would think now that the spring environment did not change because of that exception. But that is not the case. When I now request the value of the property custom.my-property (e.g. using springEnvironment.getProperty("custom.my-property"), then the spring property holds the new value ("Hello"). I didn't check yet what happened to the configuration bean, whether it still holds the old (correct) int value or not.
And now it gets even crazier: When I send a second POST request (again with a String and not an integer) to /actuator/env, no exception occurs. It seems like Spring doesn't even try to bind the value anymore to the Configuraiton bean. But when I send a third request to /actuator/env, now with a correct integer value, then the exception occurs again. So to me it looks like Spring changes the data type internally somehow. At least some kind of magic happens that I don't understand.
Now the point ist: Shouldn't there be at least some validaiton at /actuator/env when this endpoint recieves POST requests? Some validation based on the configuration bean? And what about that strange "type-alternating" behaviour I described in the previous paragraph?