ecton
commented
1 year ago After a good discussion with @daxpedda, we want to implement a "resume session" feature to allow re-establishing sessions after a configurable amount of time. We can also enable session reconnection at the TLS level both in http and fabruic which would alleviate the need protocol-level session resuming. However, I think a combination of both approaches is ideal.
The TLS-level implementation can be transparent, but there is limited ability to customize the behavior on a per-connection or per-identity basis. Protocol-level session resuming could allow different identities the ability to resume connections for longer periods of time.
The protocol-level implementation would generate new tokens periodically that the client can send back on reconnect to resume a recently disconnected session. If the server honors the token, the session can be resumed on the Client without reporting a disconnection error or unauthenticated error.
Edit: This request has been moved to #275
Since the Client's design is to automatically try reconnecting behind the scenes, an authenticated session will lose its authentication. Yet, the client's Session will continue returning the authorization information from the previous connection.
There's no easy way to reauthenticate -- the correct authentication process must be performed again. The problem is, the Client doesn't know it's unauthenticated until it returns an error.
We should store some sort of counter in the locked Client data and a copy of its value at the time of authenticating on the Session. When retrieving the session, we verify the counter matches before returning the Session, resulting in None if the Client has reconnected.