Hello all, my name is Tabeth and this is my first post. Please let me know if I'm not following any conventions surrounding the usage of this mailing list. Without further ado:
I believe it would be prudent for CouchDB to add the ability to invalidate specific sessions. There was some discussion of this on GitHub recently (https://github.com/apache/couchdb/issues/844). To summarize, the concern was that if a session token were to be taken somehow, it could be used to indefinitely re-new valid session tokens. In the thread, two methods to resolve this issue were discussed: 1. The administrator of the CouchDB instance could change the user salt or derived_key, which would invalidate all sessions for the user as well as prevent them from logging in. Presumably from this point the CouchDB administrator would send them a new password to use. 2. A user could log-out by using their password and re-saving their password to their _user document, regenerating the salt and/or derived_key, invalidating all sessions but allow them to continue to login. With this said, the two (coupled) issues I would like to discuss are: 1. Will there be support to invalidate specific sessions? 2. Are we planning on removing the auto generation of session tokens in CouchDB 2.X? To expand on these two briefly: In regards to invalidating specific sessions, I believe users are accustomed to not being logged out from all sessions on potentially different clients (mobile, browser, etc.) when they log-out from one. The log-out scheme that currently can be employed (summarized above) would log-out a user from all sessions, meaning all clients. If this is behavior we would like to remove, I would recommend the usage of a blacklist. This blacklist state could be saved in CouchDB itself, via a database, but isn't strictly necessary. An idea I had for how this could be implemented is briefly described here: https://github.com/apache/couchdb/issues/844#issuecomment-478357774. The other advantage of this is that the semantics of the _session API's DELETE would be better aligned with what would actually happen, as DELETE in this scenario could actually deactivate the session specified. Currently _session's DELETE method doesn't actually amount to much in practice. *** In regards to auto-generation of session tokens, I'm not sure of the historical reason to why this was added, but in lieu of potentially implementing (1) into CouchDB, this should be removed if at all possible. In addition, even without considering (1), removing this auto generation of session tokens would also prevent the indefinite renewal of session tokens, given one. Instead, I believe session tokens should be extended only when explicitly requested via a POST to _session with a valid username and password. *** As a final thought, if CouchDB were to remove auto-renewing sessions as well as employ a blacklist, I would recommend that the _session API be modified such that a user can specify an expiry duration in the request, with a fall-back to [couch_httpd_auth]-timeout, if none is specified. *** Finally, some open questions: 1. If we do decide to employ a blacklist, should it be stored in an internal database? * What would be the performance impact of potentially thousands of log-outs and their respective documents being added to this blacklist? * Would said blacklist be regularly purged to remove blacklist documents that have expired cookies? How would this be done? 2. What effect on legacy CouchDB usage would there be to remove automatic renewing of session tokens? I'd love to hear any and all feedback you all have. Let me know if anything I'm saying is unclear and I'll try to elaborate. Sincerely, Tabeth
