Cookie persistence is separate from auto-renewing sessions. The former makes cookies survive the closing of a browser (window), the latter is the behaviour Mike outlined correctly in the original mail. That feature was introduced when _session was added in the 0.x days, so it’d be a big change.
I think we have some vague plans to move to a server/cluster managed session solution eventually, at which point we’d be able to terminate sessions from the server end without changing the password or anything. I’d say that would be more desirable than flat out killing auto-renew. Best Jan — > On 20. Dec 2018, at 17:21, Joan Touzet <woh...@apache.org> wrote: > > Looks like the original code that introduced the option was done as part > of this work: > > https://issues.apache.org/jira/browse/COUCHDB-1304 > > One serious concern on disabling this by default is what might happen > to the replicator performance improvement introduced in 2.2.0: > > https://github.com/apache/couchdb/pull/1619 > > Nick, can you answer what happens to the replicator if we > disable allow_persistent_cookies by default? Do we lose the expires > header you need to successfully refresh, or did we fix that in 2.3.0? > My memory is poor. > > -Joan > > ----- Original Message ----- > From: "Jonathan Hall" <fli...@flimzy.com> > To: dev@couchdb.apache.org > Sent: Thursday, December 20, 2018 11:01:10 AM > Subject: Re: [PROPOSAL] Disable auto-renew of _session cookies > > The behavior you request is actually the default behavior. I ran into this > when I was expressly seeking the behavior you're trying to disable, and made > a feature request, only to learn that it is indeed configurable. See this > issue: https://github.com/apache/couchdb/issues/1598 > > In short, I believe that you simply need to disable the > allow_persistent_cookies option in your configuration. > > > > On December 20, 2018 1:42:18 PM GMT+01:00, Mike Rhodes <couc...@dx13.co.uk> > wrote: >> Hi, >> >> Currently, _session cookies auto-renew. From what I can read of the >> code, I think this is via [1] calling into [2], which will put a >> Set-Cookie header on the response. >> >> What this means, I think, is that if I can retrieve your session cookie >> in some way, then ensure I keep making calls within the expiration time >> of the original cookie and it's auto-renewed descendants, I have an >> ever-lasting way to access your CouchDB data. >> >> (Nearly everlasting, anyway, as the password update process will change >> the password hashing salt which forms a part of what the cookie's >> signature signs over. Nonetheless, this requires the user notice the >> compromise and update their password to invalidate existing sessions. >> For many attacks, it easy to get valuable data without tripping alarm >> bells.) >> >> As far as I can see, this isn't a configurable option. What are the >> thoughts of the list for removing the auto-renew function given its >> security risks? From what I understand, this has been CouchDB's >> behaviour ~forever, so I can see perhaps it's a risky change. >> >> [1]: >> https://github.com/apache/couchdb/blob/be6de6f32d0be7147dce8ebe39dd54c07d7be31f/src/chttpd/src/chttpd.erl#L1140 >> [2]: >> https://github.com/apache/couchdb/blob/1347806d2feebce53325070b475f9e211d240ddf/src/couch/src/couch_httpd_auth.erl#L246 >> >> -- >> Mike. > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/
