Hi.

According to documentation, when using spring.cloud.config.server.git.search.paths: [ "foo", "bar*" ]

the server searches for config files in the top level and in the foo/ sub-directory (...).

Is it possible to setup Config Server with Git Backend in such a way, that it will look ONLY in foo/ and not in top level and not in any other subdirectories of Git repo? And if so, than how can I achieve that?

Best regards, Piotr

Comment From: ryanjbaxter

Searching is different than using them, as long as there is no file named application or contains the application name in the top level it won't use them. That implies that if the top level is empty you wont have that problem either.

But no there is no way to prevent the config server from searching for files in the top level.

Comment From: realny

Hello, @ryanjbaxter

Thank you for your reply. I was considering a setup with a single Git repo that would keep both Spring apps configs as well as manifests for deploying apps to target platform, like Docker Swarm or k8s. This approach would allow me to have matching configurations for both Docker/Kubernetes services (especially image versions) and Spring apps within a single commit.

If I were to have /platform-manifest/ and /spring-configs/ in the same Git repo I would want to be sure that files residing in /platform-manifest/ couldn't be fetched using Config Server API. That was the reason for my question.

Best regards, Piotr

Comment From: ryanjbaxter

If you set search-paths to spring-configs it should completely ignore platform-manifest

Comment From: realny

It seems that one can abuse Config Server API to reach content of platform-manifest. Consider following config:

spring.cloud.config.server.git.search.paths: [ "spring-configs" ]

and following contents of git repo:

repo:
├── platform-manifests/
│   └──  docker-compose-apps.yml

It seems GET /platform-manifest/default/main/platform-manifest/docker-compose-apps.yml would return platform-manifests/docker-compose-apps.yml file utilising Config Server's mechanism of serving plain text.

Could config like that would be considered reliable workaround:

@Configuration
@EnableWebSecurity
public class SecurityConfig {

private static final String DISALLOWED_PATHS = "/platform-manifest/**";

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http

                .csrf(AbstractHttpConfigurer::disable)

                .authorizeHttpRequests(authorize -> authorize
                        .requestMatchers(DISALLOWED_PATHS).denyAll()
                        .anyRequest().authenticated()
                )

                .httpBasic(Customizer.withDefaults());

        return http.build();
    }
}

Comment From: ryanjbaxter

Yes, but serving the file is different from the documentation you referenced above with is relevant to a different API.

In this case you would want to secure the API with Spring Security if you want to disable unauthorized access.