It seems that Spring is not reading the customized keys for sanitizing the values.(it is only referring to default ones)
I have added below properties in application.properties file
endpoints.env.id=env
endpoints.env.sensitive=true
endpoints.env.enabled=true
endpoints.env.keys-to-sanitize=port
After starting the app and navigating to /env endpoint I am getting below response
"endpoints.env.keys-to-sanitize":{"value":"port","origin":"URL
[file:./application.properties]:40:32"},"endpoints.env.sensitive":{"value":"true","origin":"URL
[file:./application.properties]:41:25"},"endpoints.env.enabled":{"value":"true","origin":"URL
[file:./application.properties]:42:23"},"password":{"value":"******","origin":"URL
[file:./application.properties]:43:10"} ,
"management.port":{"value":"8081","origin":"URL [file:./application.properties]:36:17"}
Notice that port are still visible and the password is masked with ****.
Am I missing something. My requirement is to add few more keys to hide their values.
If you are using Spring Boot version 2 and above, the properties have changed.
You can follow the Actuator Migration Guide for more details.
Related
I learning Spring boot and found that in some examples use the same properties with the prefix spring.jpa.properties while other do it without prefix.
For instance:
The article explains second level cahche https://www.baeldung.com/hibernate-second-level-cache and autor shows example of needed properties ( example on autor's gitHub):
hibernate.cache.use_second_level_cache=true
hibernate.cache.region.factory_class=org.hibernate.cache.ehcache.EhCacheRegionFactory
But it did not work for me, and I spent few hours loking for the reason, but then i noticed, someone use prefix spring.jpa.properties. to get it working (Exact moment from video lesson):
spring.jpa.properties.hibernate.cache.use_second_level_cache=true
spring.jpa.properties.hibernate.cache.region.factory_class=org.hibernate.cache.ehcache.EhCacheRegionFactory
Which perfectly worked for me.
So my questions are:
why are they working in different way?
how to understand which properties in which cases requires this prefix?
is it probably something related to my project settings OR Spring Boot version?
any other suggestions are appreciated :)
Thank you in advance!
There are a couple of things in play here. First the tutorial you use is using plain Spring not Spring Boot. Which means a manually configured EntityManagerFactory on which you directly can set the provider specific properties. Like hibernate.cache.use_second_level_cache.
As you decided to use Spring Boot you don't have a manually configured EntityManagerFactory (although you could!). Which means you are using an autoconfigured EntityManagerFactory. Properties for this reside in the spring.jpa namespace for properties.
As it isn't feasible to specify properties for each and every extension for Hibernate (or other JPA providers) only some commonly used ones are exposed like spring.jpa.generate-ddl and a few provider specific ones in the spring.jpa.hibernate namespace. However to set all the other properties in an autoconfigured way there needed to be something else. Hence the spring.jpa.properties prefix. Anything specified in there will be passed on as is (without the said prefix ofcourse) to the EntityManagerFactory for configuration.
I have a Spring Boot application exposing REST services that are easily called on addresses like
http://localhost:8080/<controller_mapping>/<service_mapping>.
I've been asked to modify my settings in order to add a context path and have my services to respond on
http://localhost:8080//gesev-mensa/<controller_mapping>/<service_mapping>.
Thus I edited my application.properties adding
server.servlet.context-path=/gesev-mensa
Everything works but I can't call Swagger on old address
http://localhost:8080/swagger-ui/index.html?configUrl=/v3/api-docs/swagger-config#/
I get the error Failed to load remote configuration
As suggested, I tried to add property
springdoc.swagger-ui.path=/gesev-mensa/swagger-ui/index.html
but problem persists.
I guess Swagger should be reachable at
http://localhost:8080/gesev-mensa/swagger-ui/index.html?configUrl=/v3/api-docs/swagger-config#/
but that doesn't work.
Any hint?
Thanks for support.
Try removing
springdoc.swagger-ui.path=/gesev-mensa/swagger-ui/index.html
from your properties,
And your swagger will be available in
http://localhost:8080/gesev-mensa/swagger-ui/index.html
As per your current configuration with,
springdoc.swagger-ui.path=/gesev-mensa/swagger-ui/index.html
Swagger will be available in
http://localhost:8080/gesev-mensa/gesev-mensa/swagger-ui/index.html
While scouting the documentation we found the following properties that we want to set.
max-source-rows-allowed
exception-on-max-source-rows
Found on the following page:
https://teiid.github.io/teiid-documents/16.0.x/content/admin/Other_Considerations.html
However, we have tried several ways to set these without avail. The properties are not listed on the following page.
https://github.com/teiid/teiid-spring-boot/blob/master/docs/Reference.adoc
How can we set these properties?
Teiid spring boot does not currently allow setting properties like these, which are normally set in the Teiid WildFly subsystem, in an elegant way. The only workaround is to wire in your own EmbeddedConfiguration with all the appropriate settings - as the TeiidAutoConfiguration logic won't make any additional changes to a supplied configuration.
You can also log an issue / supply a patch to have this properties set from the configuration file.
I am setup to use logback with my SpringBoot application and everything is running fine and dandy.
I noticed a property called logging.path in the application.properties file which sets the value for ${LOG_PATH} in logback.xml. How does it do it?
I went through the SpringBoot logging documentation.
Any documentation I could find on property placeholder configurer
Yet I don't understand how logging.path could pass the value for ${LOG_PATH}. Though not a killer issue, I would like to know how this mapping is made.
The magic is spring will transfter logging.path into System propeties LOG_PATH.
Description from spring doc:
To help with the customization some other properties are transferred from the Spring Environment to System properties:
And it also says:
All the logging systems supported can consult System properties when parsing their configuration files. See the default configurations in spring-boot.jar for examples.
Details:
https://docs.spring.io/spring-boot/docs/1.5.6.RELEASE/reference/htmlsingle/#boot-features-custom-log-configuration
For more recent versions of Spring Boot, such as 2.5.x, the logging.file.path maps to LOG_PATH.
We're using Jasypt to encrypt some config properties (database passwords) but since the decryption key is stored on each environment's file system we have to do some manual #Bean configuration to load the password from the file then overlay loading properties with an EncryptablePropertiesPropertySource.
Because it is so manual we've had to run this code in #PostConstruct of the WebApplicationConfig class and (although this hasn't happened yet) it runs the risk of loading these after the datasource bean is configured with calls to the Environment - giving null pointer exception. #Lazy loading would be an option but obviously this means we'd then be working with fragile config which we'd like to avoid.
Ultimately we want to be able to use the default classpath:application.properties so don't want to affect existing (default) setup, but we do want to be able to use an encryptable property source as a complete replacement to the Spring one, and to have Spring load the decryption code from a file before anything else happens. Is there a way to tighter integrate loading encryptable properties earlier in the application startup and configuration?
I'm "tailoring down" my previous answer since it got deleted because it was duplicate from a different question:
This library does exactly what you need jasypt-spring-boot which is basically to allow you use the #PropertySource annotation to define your properties the same way you're use to. You just have to add an extra annotation (#EnableEncryptableProperties) to your configuration file.
It is not only limited to that, every PropertySource present in Environment will be converted to EncryptablePropertySourceWrapper, a custom wrapper that checks when a property is encrypted and decrypts it on access.
The link Dave provided in the comments section unfortunately points to nothing now, but navigating from its root I got to the following example project:
https://github.com/spring-cloud-samples/configserver (also written mostly by Dave, of course)
I think it serves as a great example for what was discussed in the comments until now.
Also, for future reference (maybe it will be done at some point), there's a Spring Framework Jira ticket for the feature of using encrypted properties: https://jira.spring.io/browse/SPR-12420