natevw edited a comment on issue #2794: URL: https://github.com/apache/couchdb/issues/2794#issuecomment-821530877
> Yes, I was missing something. […] there was no point to using a cookie over the password. but doesn't this point still stand? > One admin [sh]ould never know the actual password of another user. I.e. seems like the tradeoffs are: * store session cookie — does not expose plaintext password, but is not long-term or cross-instance valuable [which is the *benefit* of using it but will cause the replication to fail sooner or later] * store password — long-term valuable leaked personal secret, but replicator will keep working until/unless user happens to rotate their password Probably the best workaround in a multi-admin situation would be to create a shared replicator user with its own password which gets rotated via a pre-planned operation in exceptional situations (staff changes, suspected leak, scheduled policy…). Then nothing personal is leaked, and also a personal password change for personal reasons won't accidentally break existing replications. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
