-
Notifications
You must be signed in to change notification settings - Fork 979
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Token based authentication integration with core extension #3063
base: main
Are you sure you want to change the base?
Conversation
cb51afa
to
ec791b2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i can anticipate what BaseRedisAuthenticationHandler
holds but lets see the actual impl before moving further.
* @return a Flux that emits all updates to the Redis credentials | ||
*/ | ||
@Override | ||
public Flux<RedisCredentials> credentials() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TokenBasedRedisCredentialsProvider
looks nice and clean overall, and does most of the job as i understand. Only thing i got around is that i believe it would do auth twice with the same initial token;
one with a call to
public Mono<RedisCredentials> resolveCredentials() {
...
and the other with a call to
public Flux<RedisCredentials> credentials() {
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, It will do it twice.
I was thinking to skip first token when subscribing since it was used during the handshake and this way avoid the second auth, but my thinking is that between the handshake and connection activation, there might be token update that we miss (it should be very rare but still possible) and end up with expired token. Also since we are targeting long running connections where we have number of reconnects, I think it is safer to leave the initial duplication of auth to avoid complex syncronisation.
This enables use cases like credential rotation and token based auth without client disconnect. Especially with Pub/Sub clients will reduce the chnance of missing events.
dd30876
to
78a0aea
Compare
78a0aea
to
6531424
Compare
DEFAULT_REAUTHENTICATE_BEHAVIOUR
- Moved Authentication handler to DefaultEndpoint - updated since 6.6.0
1fa739e
to
78fb436
Compare
78fb436
to
98e72fb
Compare
Provide a way for lettuce clients to use token-based authentication. TOKENs come with a TTL. After a Redis client authenticates with a TOKEN, if they didn't renew their authentication we need to evict (close) them. The suggested approach is to leverage the existing CredentialsProvider and add support for streaming credentials to handle token refresh scenarios. Each time a new token is received connection is reauthenticated.
# Conflicts: # src/test/java/io/lettuce/core/AuthenticationIntegrationTests.java
d33710e
to
b7efe6c
Compare
Provide a way for lettuce clients to use token-based authentication.
TOKENs come with a TTL. After a Redis client authenticates with a TOKEN, if they didn't renew their authentication we need to evict (close) them. The suggested approach is to leverage the existing CredentialsProvider and add support for streaming credentials to handle token refresh scenarios. Each time a new token is received connection is reauthenticated.
Make sure that:
mvn formatter:format
target. Don’t submit any formatting related changes.