How can I permanently remove a record from the vault via VaultTemplate (VaultOperations)?
When I simply autowire VaultTemplate.class in my service class and try to remove, then the record data was removed but key still exits.
Related
The ask is to modify the password of a mongodb connection at runtime in a spring boot project. For example let's assume a mongodb connection is established while starting the application with password 'xyz'.I would like to modify the password at runtime by lets say hitting an api.
I have tried following solutions so far to tackle this issue:
Replacing mongoTemplate bean at runtime: Tried creating a new mongoTemplate Bean with new password at runtime and replaced it in the context using the methods given in following link. The issue with this approach is that the bean is getting refreshed only once. Ideally it should work everytime when the api to update password is being called.
Updating password in mongoCredentials: One of the obvious approach is to update the password directly in mongoCredentials since mongoTemplate uses mongoCredential class to store the credentials information.But the issue is that the password field in MongoCredentials class is 'final static' so we cannot update it even with reflections. Even though there are some tricks to update the final static fields but i'm looking for a more acceptable solution.
There is #RefreshScope in Spring Cloud project exactly for your purpose. Here is Spring's documentation about how it works: https://cloud.spring.io/spring-cloud-static/spring-cloud.html#_refresh_scope.
So all you need to do is update Environment and call org.springframework.cloud.context.scope.refresh.RefreshScope#refresh or org.springframework.cloud.context.scope.refresh.RefreshScope#refreshAll when you need to refresh your context.
I am trying to switch my http session to redis in my spring boot application.
When the first request comes to backend it's being filtered by authentication filter.
One duty of this filter is to populate user session bean with data. The session is succesfully saved to the redis instance at this step, but the delta of changes ( which should include the session bean) is not invoked. I want to point out that with storing session on tomcat the session beans work correctly.
So why session bean populated on OnePerRequest filter is not updated as the delta of session ?
Have you tried the below configuration?
#Configuration
#EnableRedisHttpSession(saveMode = SaveMode.ALWAYS)
public class RedisSessionConfig {
}
Try changing the flush mode to IMMEDIATE, by default it's ON_SAVE which means you explicitly have to save the session or in a managed environment, it happens before the response is serialized (I think).
In src/main/resources/application.properties you could do:
spring.session.redis.flush-mode=immediate
Or using #EnableRedisHttpSession do:
#EnableRedisHttpSession(redisFlushMode = RedisFlushMode.IMMEDIATE)
JaversBuilder.build() always calls MongoRepository.ensureSchema() to execute createIndex() for jv_snapshots, even when the indexes already exists.
Particularly, the createIndex permission was revoked because this command blocks all other operations on the Mongo instance (not only the database, like in MongoDB documentation) when executed in foreground.
Maybe ensureSchema could be called when configuring Javers for the application, outside JaversBuilder.build(). Example:
#Bean
public Javers javers() {
MongoRepository repository = new MongoRepository(mongoClient.getDatabase(databaseName));
Javers javers = JaversBuilder.javers().registerJaversRepository(repository).build();
repository.ensureSchema();
return javers;
}
It is appropriate to suggest the removal of the call to ensureSchema from JaversBuilder.build() or is there another way to avoid index creation on startup in a non Spring Boot application?
I am trying to build a Spring Cloud Configuration server that retrieves properties from a proprietary property server (not Git) using a RefreshScope annotation on the clients to re-inject changed properties
Since there are lots of properties and processing, I want to be able to do a conditional request, so that if no properties are changed since the supplied date, nothing will be injected.
I implemented the EnvironmentRepository interface and overrode the findOne() method to only retrieve the properties if they have changed, and otherwise return an empty map.
I also tried returning null from findOne() but that causes a NullPointerException to be thrown in the config server.
If I return the environment object, the properties are re-injected correctly, but I am trying to avoid that in the case where there are no changes
Does Spring provide some hook method where the config server can notify the config client to leave its properties as they are, and not to re-inject its properties?
Background:
I have a Spring Boot 1.4 application running with Spring Cloud. My app is using the native profile to pull settings from an external config.properties file. The config server is embedded inside the same application.
In the config.properties file I have added the following setting:
app.setting=helloworld
What works:
When I change the property and send a REFRESH event, relevant beans marked are reloaded and the change is recognized correctly.
What doesn't work:
If I actually remove the property from config.properties, (by commenting it out for instance), the REFRESH event does nothing to actually refresh the application. Spring Cloud seems to not recognize the fact that the property is removed and when the data-binder proceeds to update the state of the world it misses the fact that the property is removed, and the corresponding bean linked to it must also be refreshed and its field set to blank/null, etc.
It looks like the data-binder only looks at what is at the moment available in the configuration and does not keep record of what was vs what is.
The only way to actually disable that setting in the bean configuration state is not by removing it, but by actually setting it to a blank value (which is a new value, given the setting is just a String). Note the field in Java bean mapped to this property has no default value other than null, and the value is not defined anywhere else (as in an embedded application.properties file, etc)
What might I be missing?
Is this a feature? Bug?
Thanks for your time.
Not sure if this is applicable to you, but I had a similar issue with beans annotated with #ConfigurationProperties and registered using #EnableAutoConfiguration:
#ConfigurationProperties(prefix="example")
#RefreshScope
public class MyConfig {
private List<String> values;
}
#EnableAutoConfiguration(MyConfig.class)
public class ApplicationConfiguration {
}
The problem I was experiencing is when you had a YAML configuration like:
example:
- Some
- Values
- Here
removing items from the list did not remove them from MyConfig.values when the context is refreshed.
The cause of this was that registering MyConfig using #EnableAutoConfiguration does not allow you to change the bean's scope, meaning that the bean does not get recreated when refreshing the context. See Github Issue.
My Fix
I removed MyConfig from #EnableAutoConfiguration and explicitly added a #Component annotation:
#Component
#ConfigurationProperties(prefix="example")
#RefreshScope
public class MyConfig {
private List<String> values;
}
#EnableAutoConfiguration
public class ApplicationConfiguration {
}
After this, removing items from the YAML list gets reflected in MyConfig when the context is refreshed.
I've run into a similar issue when refreshing an external config.properties file. The issue manifested itself with my config.properties because it only had a single entry in it.
To demonstrate:
Start by overriding the application properties
application.properties
some.value=abc
config.properties
some.value=xyz
Initially, using some.value will render "xyz"
To show that the value can be updated, change the value in the config.properties
config.properties
some.value=123
Using the /refresh endpoint, refresh the context and then using some.value will render "123"
Now, by removing the property, then we can see the value does not get updated
config.properties
// now empty
Using the /refresh endpoint, refresh the context and then using some.value will still render "123". It hadn't recognised that the field had been removed, nor used the "abc" value from the application.properties.
The issue stems from the class ConfigFileApplicationListener which on line 428, identifies the properties file as empty, so doesn't load the file into the property sources that are later used to compare the new properties to the old in the ContextRefresher class. The scenario appears to keep the old one in memory.
To workaround this issue, when you only have a single property, you could add property like a.b which would force the file to be loaded with the no value and result in the correct functionality.
config.properties
a.b=true
// item removed, but use some property to make sure it's read later
Hope this helps