Document more clearly that username and password are not used when spring.data.redis.url is set about spring-boot HOT 12 CLOSED

This is an intentional design choice. In the past, we tried to combine multiple properties when configuring RabbitMQ but it was confusing for users and a source of subtle bugs. We wouldn't want to open up the possibility with Redis.

Making a change here would also be backwards incompatible as we currently document that the url overrides the host, port, username, and password:

You can either store the whole URL has a secret that's retrieved from an encrypted store, or use the separate host, port, username, and password properties and handle the username and password as secrets.

from spring-boot.

In your case (which is less lenient) we probably should manage it via error.

Yeah, that would be nice. We have MutuallyExclusiveConfigurationPropertiesException that can be thrown when multiple properties that should be mutually exclusive have been set at the same time. Unfortunately, we can't use it here as it only works well when it's added at the same time as the properties.

At the moment, if someone has host, port, username and password set somewhere, they can override them by setting the uri property. Unfortunately, there's no good way to unset a property so if we change the implementation to instead throw a MutuallyExclusiveConfigurationPropertiesException exception, we'd break things for them.

from spring-boot.

Spring Boot's docs for working with Spring Data Redis are here. They have an example that uses the host, port, username, and password properties:

spring.data.redis.host=localhost
spring.data.redis.port=6379
spring.data.redis.database=0
spring.data.redis.username=user
spring.data.redis.password=secret

Perhaps we could show an equivalent using the uri property and note the overriding behavior.

from spring-boot.

Those two examples aren't quite the same as Redis as there's no separate host and port properties, but I take your point nonetheless. I've opened #41280 so that we can review things across all of our auto-configurations. In the meantime, we can use this issue to improve the documentation for the current situation with Redis.

from spring-boot.

Configuration via URL doesn't allow username and password to be passed separately. This is problematic in a prod environment where these data need to be encrypted.

You can use placeholder as workaround:

spring.data.redis.url: redis://${spring.data.redis.username}:${spring.data.redis.password}@example.com:6379

from spring-boot.

Sorry for picking this up again, I still fell there is an bug/issue/missed there.

In your case (which is less lenient) we probably should manage it via error.
if url set and password/username set --> throw an error.

The current situation is ambiguous. I also understand that is not really a priority.

from spring-boot.

Just to clarify the reason why I got into it, as I realised it is important and not documented.

When setting redis I got the url from a cloud provider without user/password. (user password are set separately).

I looked at spring.data.redis configuration (autocompleted), picked "url" and populate it then I did the same for "username" and "password".

This was looking fine as database are configured the same way. But then when running the app, user and password weren't populated.
That was due to this ticket. I believe I am not going to be the only one to fall into it.

from spring-boot.

I've reopened this issue and repurposed it to improve the documentation.

from spring-boot.

It's already documented in the configuration property metadata.

I looked at spring.data.redis configuration (autocompleted), picked "url" and populate it then I did the same for "username" and "password".

Given that this is how @alexisgayte ended up with the faulty configuration, I'm not sure that more documentation would have helped.

from spring-boot.

That was the end of my journey. Now that I try to remember my walkthrough, I googled about redis and spring boot (trying to do the same now) and I couldn't find any good documentation to configure it using spring boot. - https://docs.spring.io/spring-data/redis/reference/redis/getting-started.html - this one is more for spring data which is good but not spring-boot.

then I picked baeldung (linked to spring I believe, very good content) https://www.baeldung.com/spring-data-redis-tutorial -

which bring me to create the ConnectionFactory and all, but when I had a look at the redis auto config class - for some reason, there were a deprecated method somewhere setPassword or setSsl which was tricky to set with the new implementation - I realised that everything was already built and nicely done via simple configuration spring.data.redis.
Then I use it to configure it and ended to create this ticket regarding the url + password.

Probably not many people got into this issue, as they probably redefine all beans following baeldung.

So yes documentation would definitely help at the first place. baeldung is not super up to date on it, probably more 2.7.x.

from spring-boot.

I definitely didn't reach the page via google.

I am not sure if that would have help to have a link here [ https://docs.spring.io/spring-data/redis/reference/redis/getting-started.html ].

One of the reason why I was going for the url too was for the protocol configuration redis:// - rediss:// - just saying.

from spring-boot.

Hum,
I am afraid to say it, but I just had another look at it,
wondering if the url protocol (ssl) is taken into account. Or at least it is treated differently than the other parameters.

also I had a look with the other data parameters and it is inconsistent. for example :

spring.neo4j.uri=bolt://my-server:7687
spring.neo4j.authentication.username=neo4j
spring.neo4j.authentication.password=secret

spring.elasticsearch.uris=https://search.example.com:9200
spring.elasticsearch.socket-timeout=10s
spring.elasticsearch.username=user
spring.elasticsearch.password=secret

May be just may be considering removing/deprecating the spring.data.redis.url is the way to go.

from spring-boot.