couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Samuel Newson <>
Subject Re: [DISCUSS] Session token invalidation
Date Thu, 18 Apr 2019 20:46:16 GMT
I think the blacklist idea is a non-starter because of the storage overhead.

However I do agree that we should end the auto extension of session cookies. You should get
exactly whatever the configured duration is and no more. When that cookie expires, or sooner
if you’re smart, you can request a new one, presenting credentials again.

We don’t want to make a change like that without a major version bump so I suggest it’s
part of 3.0.


> On 1 Apr 2019, at 15:29, Tabeth Nkangoh <> wrote:
> 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 (
> 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:
> 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

View raw message