Spring Cloud Config Uri credentials not working

Dependency:

org.springframework.cloud:spring-cloud-starter-config:2.2.2.RELEASE

According to the documentation, Uri credentials should work.

bootstrap.properties (FAILS) spring.cloud.config.uri=https://user:password@config01.mysoftware.com:9345

bootstrap.properties (WORKS) spring.cloud.config.uri=https://config01.mysoftware.com:9345 spring.cloud.config.username=user spring.cloud.config.password=password

Seems to be specific to Config since I use Uri credentials for Eureka and it works fine. The Uri is correct and verified since going to https://user:password@config01.mysoftware.com:9345/test/Dev in the browser returns the correct json.

In the case where it fails, the exception is:

Caused by: java.lang.IllegalArgumentException: Could not resolve placeholder 'someProperty1' in value "${someProperty1}"
    at org.springframework.util.PropertyPlaceholderHelper.parseStringValue(PropertyPlaceholderHelper.java:178) ~[spring-core-5.2.6.RELEASE.jar:5.2.6.RELEASE]
    at org.springframework.util.PropertyPlaceholderHelper.replacePlaceholders(PropertyPlaceholderHelper.java:124) ~[spring-core-5.2.6.RELEASE.jar:5.2.6.RELEASE]
    at org.springframework.core.env.AbstractPropertyResolver.doResolvePlaceholders(AbstractPropertyResolver.java:236) ~[spring-core-5.2.6.RELEASE.jar:5.2.6.RELEASE]
    at org.springframework.core.env.AbstractPropertyResolver.resolveRequiredPlaceholders(AbstractPropertyResolver.java:210) ~[spring-core-5.2.6.RELEASE.jar:5.2.6.RELEASE]
    at org.springframework.context.support.PropertySourcesPlaceholderConfigurer.lambda$processProperties$0(PropertySourcesPlaceholderConfigurer.java:175) ~[spring-context-5.2.6.RELEASE.jar:5.2.6.RELEASE]
    at org.springframework.beans.factory.support.AbstractBeanFactory.resolveEmbeddedValue(AbstractBeanFactory.java:912) ~[spring-beans-5.2.6.RELEASE.jar:5.2.6.RELEASE]
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1247) ~[spring-beans-5.2.6.RELEASE.jar:5.2.6.RELEASE]
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1226) ~[spring-beans-5.2.6.RELEASE.jar:5.2.6.RELEASE]
    at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:640) ~[spring-beans-5.2.6.RELEASE.jar:5.2.6.RELEASE]
    at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:130) ~[spring-beans-5.2.6.RELEASE.jar:5.2.6.RELEASE]
    at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessProperties(AutowiredAnnotationBeanPostProcessor.java:399) ~[spring-beans-5.2.6.RELEASE.jar:5.2.6.RELEASE]
    ... 14 common frames omitted

Comment From: spencergibb

There's other logging that might be useful (the exception is not). Fetching config from server at?

Comment From: SledgeHammer01

There's other logging that might be useful (the exception is not). Fetching config from server at?

@spencergibb I tried it both ways (in the uri and broken out) and the Fetching looks the same:

2020-05-13 19:04:36.416 INFO 584724 --- [ main] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at : https://config01.mysoftware.com:9345

Looking at the code, you strip the credentials off the uri anyways, so that makes sense.

Comment From: spencergibb

Care to set a breakpoint in ConfigClientProperties.extractCredentials()? This is the thing that should extract a username and password from a uri

Comment From: SledgeHammer01

Care to set a breakpoint in ConfigClientProperties.extractCredentials()? This is the thing that should extract a username and password from a uri

@spencergibb Ah, I found the issue... it's an edge case :). My password happens to contain an @ sign in it, so in the properties file, I need to url encode it as %40:

spring.cloud.config.uri=https://user:password%40@config01.mysoftware.com:9345

You are missing the url decoding step on the username and password when pulling from the Url, so it's getting added to the authorization header as "password%40" instead of "password@". In the broken out username and password, encoding isn't required, that's why it works there. If I fix the password value in the debugger, it works. I actually have the same password on Eureka and that handles the url decoding properly.