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
{{ message }}
Repository navigation
Enhance client side resolution of plain-text files #789
It seems that the only way to consume these resources (in OSS) is via RestTemplate or some similar REST client means. This can be complicated when there are additional hoops to jump through in order to resolve access to these files such as secured authentication/authorization around config server. This may require a client to muck about with authentication/authorization beans to get at the access token needed to consume those resources.
To make this easier such client situations, it would be useful to provide some means by which the clients can consume those resources, but without having to deal with the authentication/authorization specifics.
One possible (off-the-cuff) idea might be to provide some sort of ConfigServerResource or other type that would handle the OAuth concerns under the covers. Here is potential pseudo just to further elaborate the point but not yet fleshed out:
@Value("nginx.conf") // not sure this is possible with `.` in name
FileInputStream nginxConfFileStream
Regardless of the solution, ideally, the client-side piece would be part of Spring Cloud OSS generically, with hooks provided for SCS to provide OAuth details to be included in the request.
It wouldn't be a FileInputStream ever as it would come from a URL. I think the question we need to solve before any client api, is how would SCS provide the OAuth details?
Seems like a generic client app concern, rather than anything to do with config server. Maybe we should think about it as a commons feature, or spring cloud security, or even Spring Boot.
When I talked to @csterwa about this initially it was a config client feature not a server feature. My interpretation was that he just wanted a client side API that would return an InputStream rather than the developer having to figure out how to do this themselves. It seemed like more of an enhancement rather than a new feature.
Sure, but my point was that it isn't even really a config client feature. Just a resource type / resolver (which is a core Spring Framework feature, but the security angle makes it higher level concern).
Reacted by Ryan Baxter, Spencer Gibb and Krishna T
Regardless how it will be implemented, I think the ability to have a Spring Boot application to pull in, EASILY, plain text resources from a Spring Cloud configuration server would make Spring Boot more powerful. I have a Spring Boot app that uses different configuration files, camel routes, groovy scripts and velocity templates when being deployed for different customers. Currently, I deploy these custom files along with (but not part of) the Spring Boot fat jar. If it can easily pull in such files from the configuration server, then its deployment and maintenance would be significantly simplified.
Additionaly as cfg server suppoorts "labels" (which represent git rev )if would make sense that i can check "before" download loading the compelte file if the remote revison is newer then the one i arleady have retrieved.
Still can not find the code for feature that allows me to retrieve git revision for checking if my local file is outdated before updating from cfg server
"Pulling a resource" is normally something that happens in the bean lifecycle. That might happen after a refresh event, for instance. Whether that makes sense in the context of your application is up to you to decide and implement. If you want help with an actual sample app, it might be better to go to Stack Overflow (and link back here if you like).
I proposed to either implement the feature or give it away to spring project. Surely everyone can copy the code, create a library from it, implement it by it's own.
But the cleanest way is to add it to the spring project directly. It is a small compact feature so it should not be a problem.
A plain URL can already point at the config server, so the value is in reusing the client's configuration: its URIs with the same failover rules as the config data loader, the credentials, headers, token, TLS settings and timeouts, and its application name, profiles and label. The branch adds:
ConfigServerResource, a Resource for a file on the config server, with Accept: application/octet-stream for binary files.
ConfigServerResourceFactory, a bean with getResource(path) and getBinaryResource(path). With spring.config.import, it reuses the RestTemplate that loaded the configuration, registered like configDataConfigClientProperties. With the legacy bootstrap, it is auto-configured.
A ProtocolResolver, so that @Value("configserver-file:nginx.conf") Resource and ResourceLoader work.
Docs in the client section, and tests, including integration tests against a running config server.
A few questions before I open the pull request:
configserver: is already the prefix of spring.config.import, so I used configserver-file:. Would you prefer another prefix?
Binary files use a ?binary suffix, for example configserver-file:certs/truststore.p12?binary. Would a separate prefix be better?
Without a label, the client uses the useDefaultLabel endpoint, whose {path:.*} only matches one path segment, so a file in a subdirectory needs a label. Should the server endpoint match nested paths, in a separate change?
Thanks, @ryanjbaxter, that is a better starting point. PR #3355 ports ConfigResourceClient, DefaultConfigResourceClient and ConfigResourceClientAutoConfiguration from the starters into the client module, with the resolver registering configClientRestClient (and the RestTemplate behind it) at bootstrap close as the commercial OAuth2ConfigDataLocationResolver does. The only adjustments are for the open source client having no default label: the request falls back to ?useDefaultLabel, and a slash in a label is escaped as (_) like the config data loader does. The earlier resource-based branch is dropped.
Activity
spencergibb commentedon Sep 11, 2017
It wouldn't be a
FileInputStreamever as it would come from a URL. I think the question we need to solve before any client api, is how would SCS provide the OAuth details?dsyer commentedon Sep 12, 2017
Seems like a generic client app concern, rather than anything to do with config server. Maybe we should think about it as a commons feature, or spring cloud security, or even Spring Boot.
ryanjbaxter commentedon Sep 12, 2017
When I talked to @csterwa about this initially it was a config client feature not a server feature. My interpretation was that he just wanted a client side API that would return an
InputStreamrather than the developer having to figure out how to do this themselves. It seemed like more of an enhancement rather than a new feature.dsyer commentedon Sep 12, 2017
Sure, but my point was that it isn't even really a config client feature. Just a resource type / resolver (which is a core Spring Framework feature, but the security angle makes it higher level concern).
jyinpci commentedon Nov 20, 2017
Regardless how it will be implemented, I think the ability to have a Spring Boot application to pull in, EASILY, plain text resources from a Spring Cloud configuration server would make Spring Boot more powerful. I have a Spring Boot app that uses different configuration files, camel routes, groovy scripts and velocity templates when being deployed for different customers. Currently, I deploy these custom files along with (but not part of) the Spring Boot fat jar. If it can easily pull in such files from the configuration server, then its deployment and maintenance would be significantly simplified.
cforce commentedon Mar 5, 2018
Additionaly as cfg server suppoorts "labels" (which represent git rev )if would make sense that i can check "before" download loading the compelte file if the remote revison is newer then the one i arleady have retrieved.
csterwa commentedon Mar 13, 2018
This has been implemented and pulled through Spring Cloud Services Connectors.
cforce commentedon Mar 18, 2018
Would you please link the documentation for this pull?
spencergibb commentedon Mar 18, 2018
@cforce. This was not implemented in the open source project.
cforce commentedon Mar 19, 2018
https://github.com/pivotal-cf/spring-cloud-services-connector/blob/master/spring-cloud-services-spring-connector/src/main/java/io/pivotal/spring/cloud/service/config/PlainTextConfigClient.java
cforce commentedon Mar 19, 2018
https://github.com/pivotal-cf/spring-cloud-services-connector/blob/master/spring-cloud-services-spring-connector/src/main/java/io/pivotal/spring/cloud/service/config/PlainTextOAuth2ConfigClient.java
cforce commentedon Mar 19, 2018
Still can not find the code for feature that allows me to retrieve git revision for checking if my local file is outdated before updating from cfg server
spencergibb commentedon Mar 19, 2018
@cforce it's not here.
leogtzr commentedon May 29, 2018
Hello! has this been implemented?
5 remaining items
dsyer commentedon Oct 30, 2018
"Pulling a resource" is normally something that happens in the bean lifecycle. That might happen after a refresh event, for instance. Whether that makes sense in the context of your application is up to you to decide and implement. If you want help with an actual sample app, it might be better to go to Stack Overflow (and link back here if you like).
vgvineet4 commentedon Oct 30, 2018
In our use case we want to bind the resource from spring cloud config server hosted configurations to bean or instance variable of bean say ,
@bean
public class MyBean {
??how in spring bind plain text or xml config to this instance.
private String name;
}
In our use case there can be anything like security files, xml
MilosHavranek commentedon Sep 3, 2019
I created these 2 issues for text / binary resources resolution.
pivotal-cf/spring-cloud-services-connector#129
#1459
I proposed to either implement the feature or give it away to spring project. Surely everyone can copy the code, create a library from it, implement it by it's own.
But the cleanest way is to add it to the spring project directly. It is a small compact feature so it should not be a problem.
spencergibb commentedon Sep 3, 2019
@csterwa maybe we could port the non-oauth version here. See comments in #1459
MilosHavranek commentedon Oct 4, 2019
It has been a month. Can someone eligible please respond?
spencergibb commentedon Oct 4, 2019
@SpiReCZ this enhancement has not been scheduled for addition at this time. When it has, it will be added to a Project and Milestone.
mrodal commentedon Jun 24, 2024
Any plans on adding this feature?
ryanjbaxter commentedon Jun 24, 2024
Not at the moment, but if you are interested in submitting a PR for it that would be welcome!
vibAtCryptomathic commentedon Jun 12, 2025
Is this approach also intended to work for binary files?
I.e. is there a way to add the
Accept: application/octet-stream-header (cf. https://docs.spring.io/spring-cloud-config/docs/current/reference/html/#_serving_binary_files ), when using a resource in my client app?For instance,
my.property=http://my-config-server/path/to/binary-file.sharanggupta commentedon Oct 21, 2026
@ryanjbaxter, I'd like to pick this up. I have a working branch to show the shape before opening a pull request: main...sharanggupta:spring-cloud-config:gh-789-config-server-resources
A plain URL can already point at the config server, so the value is in reusing the client's configuration: its URIs with the same failover rules as the config data loader, the credentials, headers, token, TLS settings and timeouts, and its application name, profiles and label. The branch adds:
ConfigServerResource, aResourcefor a file on the config server, withAccept: application/octet-streamfor binary files.ConfigServerResourceFactory, a bean withgetResource(path)andgetBinaryResource(path). Withspring.config.import, it reuses theRestTemplatethat loaded the configuration, registered likeconfigDataConfigClientProperties. With the legacy bootstrap, it is auto-configured.ProtocolResolver, so that@Value("configserver-file:nginx.conf") ResourceandResourceLoaderwork.A few questions before I open the pull request:
configserver:is already the prefix ofspring.config.import, so I usedconfigserver-file:. Would you prefer another prefix??binarysuffix, for exampleconfigserver-file:certs/truststore.p12?binary. Would a separate prefix be better?useDefaultLabelendpoint, whose{path:.*}only matches one path segment, so a file in a subdirectory needs a label. Should the server endpoint match nested paths, in a separate change?ryanjbaxter commentedon Oct 22, 2026
It looks like there is a solution implemented for this upstream in our commercial offering
https://github.com/pivotal-cf/spring-cloud-services-starters/blob/main/spring-cloud-services-config-client-autoconfigure/src/main/java/io/pivotal/spring/cloud/config/client/DefaultConfigResourceClient.java
https://github.com/pivotal-cf/spring-cloud-services-starters/blob/main/spring-cloud-services-config-client-autoconfigure/src/main/java/io/pivotal/spring/cloud/config/client/ConfigResourceClientAutoConfiguration.java
https://github.com/pivotal-cf/spring-cloud-services-starters/blob/main/spring-cloud-services-config-client-autoconfigure/src/main/java/io/pivotal/spring/cloud/config/client/OAuth2ConfigDataLocationResolver.java#L108-L126
I think the right solution here is to backport this into spring cloud config and use what we know already works
sharanggupta commentedon Oct 22, 2026
Thanks, @ryanjbaxter, that is a better starting point. PR #3355 ports
ConfigResourceClient,DefaultConfigResourceClientandConfigResourceClientAutoConfigurationfrom the starters into the client module, with the resolver registeringconfigClientRestClient(and theRestTemplatebehind it) at bootstrap close as the commercialOAuth2ConfigDataLocationResolverdoes. The only adjustments are for the open source client having no default label: the request falls back to?useDefaultLabel, and a slash in a label is escaped as(_)like the config data loader does. The earlier resource-based branch is dropped.Use the import's credentials, URIs, labels and a size limit in the Co…