Tighten rules around profile naming

[onobc]

If you set spring.profiles.active to a value that contains a * the app will fail to start.

Steps to reproduce

Spring Boot 3.0.2 simplest application from start.spring.io:

@SpringBootApplication
public class WackyProfileApplication {
	public static void main(String[] args) {
		SpringApplication.run(WackyProfileApplication.class, args);
	}
}

Start it w/ spring.profiles.active set to foo*bar via any normal means such as:

• sysprop
• envvar
• property in application.yml
• profile property in maven/gradle plugin

App fails to start and reports the following in the log:

com.example.wackyprofile.WackyprofileApplication
23:14:37.244 [main] ERROR org.springframework.boot.SpringApplication - Application run failed
java.lang.IllegalStateException: Location 'file:./application-foo*bar.yaml' must end with '*/'
	at org.springframework.util.Assert.state(Assert.java:97)
	at org.springframework.boot.context.config.LocationResourceLoader.validatePattern(LocationResourceLoader.java:134)
	at org.springframework.boot.context.config.LocationResourceLoader.getResources(LocationResourceLoader.java:95)
	at org.springframework.boot.context.config.StandardConfigDataLocationResolver.resolvePattern(StandardConfigDataLocationResolver.java:313)
	at org.springframework.boot.context.config.StandardConfigDataLocationResolver.resolve(StandardConfigDataLocationResolver.java:299)
	at org.springframework.boot.context.config.StandardConfigDataLocationResolver.resolve(StandardConfigDataLocationResolver.java:251)
	at org.springframework.boot.context.config.StandardConfigDataLocationResolver.resolveProfileSpecific(StandardConfigDataLocationResolver.java:150)
	at org.springframework.boot.context.config.ConfigDataLocationResolvers.lambda$resolve$2(ConfigDataLocationResolvers.java:107)
	at org.springframework.boot.context.config.ConfigDataLocationResolvers.resolve(ConfigDataLocationResolvers.java:113)
	at org.springframework.boot.context.config.ConfigDataLocationResolvers.resolve(ConfigDataLocationResolvers.java:106)
	at org.springframework.boot.context.config.ConfigDataLocationResolvers.resolve(ConfigDataLocationResolvers.java:94)
	at org.springframework.boot.context.config.ConfigDataImporter.resolve(ConfigDataImporter.java:105)
	at org.springframework.boot.context.config.ConfigDataImporter.resolve(ConfigDataImporter.java:97)
	at org.springframework.boot.context.config.ConfigDataImporter.resolveAndLoad(ConfigDataImporter.java:85)
	at org.springframework.boot.context.config.ConfigDataEnvironmentContributors.withProcessedImports(ConfigDataEnvironmentContributors.java:115)
	at org.springframework.boot.context.config.ConfigDataEnvironment.processWithProfiles(ConfigDataEnvironment.java:313)
	at org.springframework.boot.context.config.ConfigDataEnvironment.processAndApply(ConfigDataEnvironment.java:234)
	at org.springframework.boot.context.config.ConfigDataEnvironmentPostProcessor.postProcessEnvironment(ConfigDataEnvironmentPostProcessor.java:96)
	at org.springframework.boot.context.config.ConfigDataEnvironmentPostProcessor.postProcessEnvironment(ConfigDataEnvironmentPostProcessor.java:89)
	at org.springframework.boot.env.EnvironmentPostProcessorApplicationListener.onApplicationEnvironmentPreparedEvent(EnvironmentPostProcessorApplicationListener.java:109)

Cause

The * qualifies it to be processed as a pattern in StandardConfigDataLocationResolver#resolve(StandardConfigDataReference)

[onobc]

This is an edge-casey situation and arguably a terrible choice to include a wildcard in your profile name. However, there is no place in the Spring Boot nor Spring Framework docs (that I could find) that guide the user to the rules for a profile name. Maybe just adding a small section to the docs would suffice.

[onobc]

Another interesting point, there is a validateProfile in Environment whose only requirement is that the profile has text and does not begin w a !. Different consumers of the profile probably have different validation requirements than others.

[philwebb]

I think we should tighten the rules for Spring Boot applications. The application-<profile> file is one example of something that will break but I suspect there are others. For example , will probably break the list parsing and !, &, | will break Profiles.of.

[wilkinsona]

We've had an issue related to , in the past: #19537

[bbulgarelli]

I started working on this issue and I added the following code in the beginning of SpringBootContextLoader.setActiveProfiles:

private void setActiveProfiles(ConfigurableEnvironment environment, String[] profiles, boolean applicationEnvironment){
    ***
    for (String profile : profiles) {
        if (containsProhibitedCharacters(profile)) {
            throw new IllegalArgumentException("Invalid profile: '" + profile + "'. Profile names can't contain '*', '&', '!' or '|'.");
        }
    }
    ***
}

And I also created the following method:

private boolean containsProhibitedCharacters(String str){
	String regex = ".*[*&!|].*";
	return str.matches(regex);
}

I didn't include , in the regex expression, because it would break the following unit test that already exists:

@Test
void activeProfileWithComma() {
	assertThat(getActiveProfiles(ActiveProfileWithComma.class)).containsExactly("profile1,2");
}

I would like to know if the changes I made solve the issue correctly. If they do, what should I do about the comma problem?

P.s.: I also made the unit tests that verify the changes I made.

[philwebb]

Thanks for looking at this @bbulgarelli. Looking at commit 7ab2bca it seems like we added the profile test when fixing #19537. I think we added the comma test for completeness, but I think it's fine to remove it. A better exception would have actually helped the reporter of #19537.

Feel free to submit a pull-request if you have something you'd like us to review.