Closed Noxaro closed 4 years ago
eleftherias
commented
4 years ago Thanks for getting in touch @Noxaro.
There have been some similar issues reported in the Spring Data Redis project.
Could you take a look at https://jira.spring.io/browse/DATAREDIS-1154 and https://jira.spring.io/browse/DATAREDIS-1142 and see if either of those applies to your situation?
Noxaro
commented
4 years ago Hi @eleftherias
redis enterprise handles all the clustering stuff internaly.
So our application connects to a single instance endpoint and redis enterprise does the clustering magic.
But a sharded redis enterprise cluster comes also with some trade offs like that multi key operations like RENAMEare not supported.
=> https://docs.redislabs.com/latest/rc/concepts/clustering/
With that said our application connects to redis enterprise with a single instance configuration, as this is the recommended way. I've tested spring session data redis with a little spring boot app to make sure spring-security-oauth has no impact on the described problem. The relevant configuration part here is the application.yml which contains the following:
spring:
session:
store-type: redis
redis:
namespace: redis
redis:
host: redis-12345.******.europe-west4-mz.gcp.cloud.rlrcp.com
port: 12345
password: ********
With that configuration the same exception is thrown as described above.
Also a key rename is not possible when you try it on the redis-cli. Here is the output of it:
redis-12345.******.europe-west4-mz.gcp.cloud.rlrcp.com:12345> SET test value
OK
redis-12345.******.europe-west4-mz.gcp.cloud.rlrcp.com:12345> RENAME test test1
(error) CROSSSLOT Keys in request don't hash to the same slot (command='RENAME', original slot=6918, wrong slot=4768, first key='test', violating key='test1')With that in mind i think both tickets are describing another problem then we have.
Best Regards Noxaro
rwinch
commented
4 years ago @Noxaro Thanks for the additional details. Given that Spring Security must invoke HttpServletRequest.changeSessionId() to change the session id at log in to prevent session fixation attacks, what would you expect Spring Session to do differently?
Noxaro
commented
4 years ago Hi @rwinch,
the reason for this issue was to get an idea of where to implement a fix for the redis enterprise key rename handling.
Yesterday i took a look into the source code of spring-session and spring-data-redis. I think you are right, spring-session can't do anything in this case. The fix for the multi key operations should be implemented in spring-data-redis.
With this information i think we can close this issue. We are going forward to get in touch with the spring-data-redis project.
Best Regards Noxaro
rwinch
commented
4 years ago Thanks for the response. I'll close this issue.
For what it is worth, you could work around this by providing a custom implementation of RedisOperations that delegates to an existing implementation for operations that work, but then does something custom for operations like rename.
qiang1129
commented
4 years ago https://github.com/spring-projects/spring-session/blob/master/spring-session-data-redis/src/main/java/org/springframework/session/data/redis/RedisSessionRepository.java line 153 private String getSessionKey(String sessionId) { return this.keyNamespace + "sessions:" + sessionId; } this code can change with this？ private String getSessionKey(String sessionId) {
return this.keyNamespace + "sessions:{" + sessionId+“}”;
}
fyeeme
commented
3 years ago @qiang1129 you can try it like this: edit application.properties and add below code.
spring.session.redis.namespace="{spring}:{session}"
ngdinhtoan
commented
4 months ago @qiang1129 you can try it like this: edit application.properties and add below code.
spring.session.redis.namespace="{spring}:{session}"
May I ask why? How is it different from the default one spring:session?
Expected Behavior
I can use a sharded redis enterprise labs cluster with spring session data redis without getting crossslot violations because of unallowed key renames.
Current Behavior
When i use spring session redis with redis enterprise labs it comes to cross slot violations when someone tries to login. This ends up in 500 internal server error as the session key can not be changed.
Context We built an oauth2 authorization server based on the spring boot stack and redis. As our service grew we needed to scale it out. Initially we used redis open source which made it hard for us to meet our scaling requirements. To solve this we migrated to Redis Labs Enterprise Cluster (used through Google Cloud Platform). While this worked out very well scaling wise we now have the issue that the only working session driver redisson is not as stable as we'd like it to be. Our first choice would be Spring Session as it's integrated well with the Spring Boot stack but unfortunately there's no support for Redis Labs Enterprise Cluster (RLEC). As fas as we know, the reason for this is that RLEC behaves like a standalone redis server but doesn't support multi-key commands such as
rename. The point is that within Spring Session the redisrenamecommand is being used inRedisSessionStore/RedisIndexedSessionStore::saveChangedSessionId()(https://github.com/spring-projects/spring-session/blob/master/spring-session-data-redis/src/main/java/org/springframework/session/data/redis/RedisIndexedSessionRepository.java#L831) to rename the key (which includes the current session key). The question here is where do you see the support for RLEC? Spring Session or Spring Data Redis? I am asking because we're currently facing the issue as described above and would like to contribute. Thank you for your feedback and guidance!Best Regards Noxaro