Limiter l'accès aux ressources dans CouchDB à exactement 2 utilisateurs

Question

Actuellement, je suis en train d'évaluer CouchDB pour un nouveau projet.

La principale contrainte pour ce projet est une forte confidentialité. Il doit y avoir des ressources lisibles par exactement deux utilisateurs.

Une utilisation peut être similaire aux messages directs (DM) sur Twitter. Une autre utilisation serait le niveau d'accès Utilisateur/Super utilisateur.

Je n'ai actuellement aucune idée sur la façon de résoudre ce genre de problèmes avec CouchDB autre que de créer une base de données qui est accessible uniquement par ces 2 utilisateurs. Je me demande comment puis-je construire des vues agrégeant des données provenant de plusieurs bases de données?

Avez-vous des conseils ou des suggestions pour moi?

Answer 1

J'ai posé cette question à plusieurs reprises sur les listes de diffusion de CouchDB, et n'a jamais eu de réponse.

Il y a un certain nombre de choses que couchdb manque.

L'un d'eux est le document de sécurité de niveau qui:

• autoriser uniquement certains utilisateurs de visualiser un filtre doc
• les documents indexés dans une vue sur une base de l'autorisation de niveau utilisateur

Je ne pense pas qu'il y ait une solution aux considérations d'autorisation avec l'implémentation actuelle de couchdb. Une solution consisterait à utiliser un outil d'indexation externe tel que lucene, à étiqueter vos documents avec des droits d'utilisateur, puis à émettre une requête lucene avec la définition de l'utilisateur afin d'obtenir les docs. Cela implique également une charge supplémentaire sur vos serveurs (Lucene requiert une JVM) et un délai supplémentaire pour que les données soient disponibles (temps d'indexation Lucene ...)

En ce qui concerne la solution de plusieurs bases de données, il existe un cadre de langage implémentations qui ne permettent tout simplement pas d'utiliser plus d'une base de données (par exemple couch_potato pour Ruby). Avoir plusieurs bases de données signifie également que vous aurez plusieurs processus de réplication si vos bases de données sont répliquées.

Cela signifie également que les vues seront mises à jour pour chaque base de données.Dans certains cas, il vaut mieux avoir des vues énormes indexées dans une base de données unique, mais cela signifie également que des utilisateurs distincts pourraient ne pas être à jour pour une seule source d'information (certains auront leurs vues mises à jour, d'autres pas). Vous ne pouvez donc pas garantir que les données sont cohérentes pour tous les utilisateurs. Donc, à moins que quelque chose ne soit implémenté dans le noyau du canapé pour gérer les autorisations au niveau du document, CouchDB ne semble pas approprié pour la gestion des données avec des contraintes de confidentialité.

Answer 2

Il manque un certain nombre de détails sur ce que vous essayez d'accomplir, à quoi ressemblent les données, il est donc difficile de faire une recommandation spécifique. Vous pouvez créer une base de données par utilisateur et copier des éléments dans chaque base de données d'utilisateurs (pour le cas d'utilisation de DM que vous avez décrit). Chaque utilisateur ne pourrait accéder qu'à sa propre base de données, et un administrateur pourrait accéder à toutes les bases de données. Si vous devez ultérieurement mettre à jour ces enregistrements, les copier dans plusieurs bases de données n'est peut-être pas une bonne idée. Vous pouvez ensuite décider si vous souhaitez contrôler les autorisations à un niveau différent du stockage.

Pour les vues qui regroupent des données provenant de plusieurs bases de données, je recommande de regarder lounge et bigcouch, qui prennent des approches différentes.

http://tilgovi.github.com/couchdb-lounge/ http://support.cloudant.com/faqs/views/chained-mapreduce-views