Open kentonv opened 7 years ago
Tying token cleanup to session deletion does not solve this problem completely.
When a client loses connectivity for a few minutes, the session gets deleted. If the client regains connectivity, then a session is restored with the same ID and everything ought to work as before. If the app expects the token to remain valid as long as the session, then deleting the token upon session deletion seems problematic, because how would we restore the token upon session restore?
If anything, I'm tempted to make the current 10 minute timeout shorter, so that apps are not tempted to rely on the tokens being long-lived.
Currently we delete clientPowerboxRequest tokens after a certain timeout. However, it is very convenient for apps if they can expect these tokens to stick around for the duration of a UI interaction, e.g. so that if the user selects a powerbox capability as part of a form but never clicks "submit", the app server never has to claim the request and doesn't end up with an orphaned capability.
(The feature key vendor currently works this way, which means that if someone stays on the purchase form for >10 minutes after choosing their email or payment source, submitting the form will fail.)
Since clientPowerboxRequest contains sessionId, we could instead delete all these tokens when the session is deleted, i.e. shortly after the user closes the session.