Supports multiple instances using different credentials #300
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
Although a program can currently create multiple instances of nano, they all share the same cookie jar. Authorizing with a set of credentials in one instance changes the credentials (the AuthSession cookie) used by all instances.
This change gives every instance of nano its own cookie jar, so each instance can use a different set of credentials. One application server can thus service the requests of multiple CouchDB users.
The cookie jar is visible to the code instantiating nano, so it can re-create cookies for the following architecture: An application server can accept a CouchDB username and password from a client web app, pass them to a CouchDB cluster, then pass the value of the AuthSession cookie back to the client web app. In future requests, the client can then pass the value of the AuthSession cookie back to the application server, which re-creates the AuthSession cookie. As long as a client web app retains the value of the AuthSession cookie, the application server can thus handle requests without requiring the client web app to pass the username and password, even if the application server was restarted after the client web app authenticated, or didn't handle the authentication.
This supports application servers implementing the adapter pattern.
My current work is implementing an adapter for Armadietto, which implements the remoteStorage protocol.
Testing recommendations
The test 'should be able to authenticate - POST /_session - nano.auth' has been extended to cover using two instances of nano and verifying that they retain separate credentials. (Running this extended test without the code changes demonstrates that the current implementation cannot maintain separate sets of credentials.)
It also works for an actual adapter: https://github.com/DougReeder/armadietto/tree/couchdb-auth