Closed vimalk78 closed 7 years ago
i think this is a problem even when using embedded v3 client.
@vimalk78 yes, current simple token has a problem of not having timeout mechanism. I'm planning to add the mechanism after finishing jwt token support: https://github.com/coreos/etcd/pull/6082
@mitake Can we fix this for simple token first? We will support jwt in 3.2 not 3.1
@xiang90 , @mitake what is your idea about invalidating the tokens, remove after session is closed, or have a keep alive time and remove after timeout
@xiang90 ok, then I'll fix the simple token first.
@vimalk78 removing after a timeout would be good. Do you have any ideas?
@mitake , removing the token as soon as the session closes will be best. next best thing is to remove earlier token for the same user when user gets authenticated again. this way we wont need a timer based approach. with timer based approach we will also need mechanism for clients to reset the timer, if they choose to continue the session, else forcing to authenticate again.
@xiang90 , @mitake may i work on this and send a PR ?
@vimalk78 of course, it will be great.
@xiang90 should we finish it before releasing 3.1.0? Then I should work on it instead of @vimalk78 for finishing soon. If backporting is ok, I can cooperate with @vimalk78
my solution direction is to remove the simpleToken when the client closes connection. so was trying to find the hook in grpc for the same. https://groups.google.com/forum/#!topic/grpc-io/EIcQlLqlNQg
for now i can finish by checking for any existing token for username in the auth.assignSimpleTokenToUser
and removing it before adding the new Token
The Token generated for a user during Authentication is being cached in
auth/authStore
All tokens for a user are being removed when a user is deleted, or the user changes password, but not removed when the user session closes, or the same user gets authenticated again.ideally the token should be removed when the authenticated session is over. at least it should be removed when the same user gets a new Token.
currently, if etcdctl is used for many operations with auth enabled, the map size keeps on growing.
The above modified code prints the following log.
17:35:39 etcd1 | 2016-09-29 17:35:39.365732 E | auth: added user root , total = 1 17:35:39 etcd2 | 2016-09-29 17:35:39.377584 E | auth: added user root , total = 1 17:35:39 etcd3 | 2016-09-29 17:35:39.379829 E | auth: added user root , total = 1 17:35:52 etcd1 | 2016-09-29 17:35:52.018620 E | auth: added user root , total = 2 17:35:52 etcd3 | 2016-09-29 17:35:52.023928 E | auth: added user root , total = 2 17:35:52 etcd2 | 2016-09-29 17:35:52.037939 E | auth: added user root , total = 2 17:35:53 etcd3 | 2016-09-29 17:35:53.858867 E | auth: added user root , total = 3 17:35:53 etcd1 | 2016-09-29 17:35:53.871008 E | auth: added user root , total = 3 17:35:53 etcd2 | 2016-09-29 17:35:53.880090 E | auth: added user root , total = 3 17:35:55 etcd1 | 2016-09-29 17:35:55.794764 E | auth: added user root , total = 4 17:35:55 etcd2 | 2016-09-29 17:35:55.799397 E | auth: added user root , total = 4 17:35:55 etcd3 | 2016-09-29 17:35:55.812799 E | auth: added user root , total = 4 17:35:57 etcd3 | 2016-09-29 17:35:57.196612 E | auth: added user root , total = 5 17:35:57 etcd2 | 2016-09-29 17:35:57.221568 E | auth: added user root , total = 5 17:35:57 etcd1 | 2016-09-29 17:35:57.229336 E | auth: added user root , total = 5 17:35:58 etcd2 | 2016-09-29 17:35:58.512297 E | auth: added user root , total = 6 17:35:58 etcd3 | 2016-09-29 17:35:58.526757 E | auth: added user root , total = 6 17:35:58 etcd1 | 2016-09-29 17:35:58.528447 E | auth: added user root , total = 6 17:35:59 etcd2 | 2016-09-29 17:35:59.872109 E | auth: added user root , total = 7 17:35:59 etcd1 | 2016-09-29 17:35:59.877785 E | auth: added user root , total = 7 17:35:59 etcd3 | 2016-09-29 17:35:59.885849 E | auth: added user root , total = 7