Est-ce que CouchDB 2 synchronise les sessions utilisateur entre les nœuds?

Question

Je travaille actuellement sur une configuration docker-composer qui peut être utilisée pour déployer un cluster de nœuds CouchDB 2. J'ai finalement réussi à faire fonctionner les nœuds et à synchroniser les données entre les nœuds, mais à moins que je ne me trompe, il semble que CouchDB ne synchronise pas les sessions utilisateur.

Ma configuration a 3 nœuds et utilise une configuration haproxy presque identique à haproxy.cfg. Selon ma configuration, haproxy achemine le trafic entrant sur le port 5984 vers le port 5984 sur les 3 nœuds.

Supposons un nom d'utilisateur admin de root et un mot de passe de password.

je suis Connectez-vous avec:

curl -vX POST http://localhost:5984/_session -H 'Content-Type: application/x-www-form-urlencoded' -d 'name=root&password=password' 

Notez le AuthSession retourné est utilisé ci-dessous comme AUTHSESSION.

Ensuite, j'exécutez la commande suivante: «Vous n'êtes pas un administrateur de serveur »

curl -X PUT http://localhost:5984/mydb --cookie AuthSession=AUTHSESSION -H "X-CouchDB-WWW-Authenticate: Cookie" -H "Content-Type: application/x-www-form-urlencoded" 

Cela échoue généralement avec je peux continuer à émettre le même PUT et il finira par réussir comme je suppose que haproxy éventuellement achemine la demande vers le nœud unique avec lequel je suis authentifié. Comme haproxy utilise round robin, il y a 1 chance sur 3 que j'atteigne le nœud cible.

Je pense que CouchDB 2 pourrait gérer la synchronisation des sessions utilisateur entre les nœuds. Est-ce que je fais une supposition stupide ici?

(S'il vous plaît voir run cluster via docker-compose pour reproduire ma configuration)

Mise à jour avec une solution spécifique pour ma configuration docker-Compose

Comme par @lossleader, vous devez définir le secret dans la section [couch_httpd_auth] de sorte qu'il est identique à travers les nœuds. De plus, vous devez définir le même nom d'utilisateur et mot de passe administrateur dans la section [admins]. Le détail que j'ai manqué ici est que tous les nœuds doivent avoir exactement le même mot de passe dans le fichier .ini. Avoir le même mot de passe en clair n'est pas suffisant, sinon chaque noeud va générer son propre sel et générer un hash différent.

Voir run cluster via docker-compose pour mon installation complète.

Answer 1

Réponse courte: oui.

Réponse longue:

Comme d'autres l'ont commenté, CouchDB ne connaît pas les sessions de son faite, il est vrai qu'il ya pas de mécanisme pour synchroniser eux-mêmes sessions, mais il y a deux choses non-session que vous devez synchroniser vous-même avant qu'un cookie de session effectué sur un nœud d'un cluster sera valide sur un autre.

[couch_httpd_auth] secret = foo

C'est la valeur secrète utilisée pour signer les cookies de session. S'il n'est pas présent lorsqu'un cookie de session est demandé, il est défini sur une valeur aléatoire. Chaque noeud d'un cluster va naturellement générer une valeur différente. Donc, avant le démarrage, faites en sorte que cette valeur soit définie sur une grande valeur aléatoire, mais la même chose sur tous les nœuds de votre cluster.

[admins] foo = -pbkdf2-2cbae77dc3d2dadb43ad477d312931c617e2a726,cd135ad4d6eb4d2f916cba75935c3ce7,10

Cette section contient le mot de passe de chaque hash salé utilisateur admin. Le sel est inclus dans la signature dans les cookies de session. Lors de la modification du mot de passe, le sel est re-randomisé, de sorte que l'ajout de sel a pour effet d'invalider les cookies de session avant la modification du mot de passe.

Vous avez également besoin que cette section soit la même sur tous les nœuds. Chaque noeud génère un sel aléatoire lors du hachage du mot de passe administrateur.

Il est préférable de générer cette section de manière externe dans le cadre de l'automatisation de l'approvisionnement des noeuds.

J'espère que vous avez commencé. Nous aimerions améliorer cette situation dans une future version, cela reflète évidemment les versions de la pré-clustering de couchdb.

Answer 2

Les jetons de session CouchDB sont simplement un hachage HMAC du mot de passe de l'utilisateur, du secret du serveur et de l'heure. Les sessions ne sont pas stockées dans CouchDB, même sur un système à un seul nœud. Donc, il n'y a rien à synchroniser.

Vous pouvez, et beaucoup le font, générer des sessions entièrement programmées, externes à CouchDB.