The problem/use-case that the feature addresses

I recently found that temporary passwords are very useful when using smart door locks. It allows temporary or short-term visitors to enter the home. Therefore, in the application scenario of redis, I wonder if there is a need to use temporary passwords.

Description of the feature

For example, there is a business that needs to access redis resources, but it may only be accessed for one month. According to the existing redis implementation, we may provide him with a separate user, and this user needs to be deleted after one month, but one month Later we may forget about this matter, so that the temporary user is postponed or not deleted at all.

ACL SETUSER user123 on >password ~* +@all

Assuming that redis supports setting a validity period for user passwords, for the above scenario, we can run:

ACL SETUSER user123 on >password ~* +@all 30days

During this period, if the business expects to extend the usage time, such as expecting to continue to use it for 60 days, then we can run:

ACL SETUSER user123 on >password ~* +@all 60days

According to this implementation, after the expiration, the corresponding password is automatically deleted or marked as expired, and the service will not be able to continue to access redis through this user, thus automatically realizing the user password validity period management.

Some detail design:

  • The meaning of the password validity period: from the moment when the password validity period is set, how long before it expires;
  • The detection method of the validity period of the password: compare the current time with the timestamp of the expiration moment (the timestamp of the expiration moment needs to be recorded);
  • After the password expires, it can be automatically deleted or marked as expired. If the user has only one password, the user will be marked as off after the password expires;

Alternatives you've considered

Of course, we can let the external component control the validity period of the user's password. After the expiration, the external component deletes the corresponding user's password. But I think redis's own control will be more elegant.

Additional information

I'm currently trying to implement it, if everyone is interested in this idea, I can go ahead and submit a PR later.

Comment From: ivwsai

我也有这个需求,最后是自己定时清理了

Comment From: joyanhui

I also need a password /token expiration time when using redis as an mq server