The new login implementation with state & nonce checks as per Login.gov included several new objects that are stored inside redis to get the implementation to work correctly. We need to clean these out in an efficient/effective way. If there is a way to set an expiration on these, that would be, in my opinion, the most effective and efficient way to approach it. However if that is not possible, then we need to delete them from the cache after they are no longer necessary - but this would mean that there could be objects stored in the cache which are never cleaned up.
The amount of time to live for these should be no greater than the length of time that an invite is good for - 24 hours. Any of these objects (the login-state, login-nonce, and I believe login-data objects) all need to expire after that time, most of this exists in redis for admin, but I believe there might be something in api which needs to be cleaned out.
The new login implementation with state & nonce checks as per Login.gov included several new objects that are stored inside redis to get the implementation to work correctly. We need to clean these out in an efficient/effective way. If there is a way to set an expiration on these, that would be, in my opinion, the most effective and efficient way to approach it. However if that is not possible, then we need to delete them from the cache after they are no longer necessary - but this would mean that there could be objects stored in the cache which are never cleaned up.
The amount of time to live for these should be no greater than the length of time that an invite is good for - 24 hours. Any of these objects (the login-state, login-nonce, and I believe login-data objects) all need to expire after that time, most of this exists in redis for admin, but I believe there might be something in api which needs to be cleaned out.
See: https://www.dragonflydb.io/code-examples/python-redis-delete-key-after-time