Closed vsingal-p closed 2 years ago
Please implement your own authentication scheme.
Picking up the token file as a fallback and on presence in its default location is a convenience functionality. We do not want to enhance configuration options any further.
But given this package is using using ConfigData API to load properties, it is not possible to tap the startup process and load token via file which can be used by spring cloud vault
It is possible to register a custom ClientAuthentication
by calling ConfigurableBootstrapContext.register(ClientAuthentication.class, () -> your client authentication)
through a BootstrapRegistryInitializer
as in
SpringApplication application = new SpringApplication(…);
application.addBootstrapRegistryInitializer(registry -> registry.register(…));
It's a bit more difficult to get hold of property values within a BootstrapRegistryInitializer
but that's a question rather for Spring Boot.
Okay, we could try that But if we are allowing token to be read from a fallback file, why is customising the location of that file an issue?
The default fallback works for unix based OS, like macOS, but it won't work for Windows anyway. So I think there's a strong reason to have the flexibility to define location of that file
Because it introduces new configuration elements.
A configuration around the same token based auth. If we are allowing token to be read from file, the location of that file should not be an issue IMO. Plus this introduces development gap. A developer working on an application on MacOS, cannot share the same with a developer using Windows without one of them having certain hacks.
The longer reply is that now we start with a path, the next one wants to read the token from a remote server or an URL and another one wants to get the token from a service. We have to draw a line somewhere as we do not want to introduce insecure elements into Spring Vault/Spring Cloud Vault.
Feel free to fork this project and introduce the necessary changes in a development line that suits your needs.
A developer working on an application on MacOS, cannot share the same with a developer using Windows without one of them having certain hacks.
It's not our goal to compensate for operating system differences.
Thanks for the clarification @mp911de 👍
In #609 support was added to fetch token via the token file as fallback if token is not provided as property. However, the location of fallback file is hardcoded within spring-cloud-vault.
We have a requirement to use a custom path and name for the token file. We have multiple environments, and due to some constraint the paths in them are different.
Can we have something like this in which we can provide the fallback location?