Comme dans MongoDB 3.4, la granularité du contrôle d'accès intégré ne va que jusqu'au contrôle d'accès au niveau de la collection.
Par exemple, vous pouvez créer un rôle défini par l'utilisateur limitant les privilèges pour une collection :
privileges: [
{ resource: { db: "db_ANIMAL", collection: "tb_BIRD" }, actions: [ "find", "update" ] }
]
Pour limiter l'accès en lecture seule à un sous-ensemble de données de collecte, vous pouvez envisager d'utiliser la nouvelle fonctionnalité Vues dans MongoDB 3.4 ou d'implémenter la rédaction au niveau du champ à l'aide de $redact étape d'agrégation (MongoDB 2.6+).
Si vous avez besoin d'un contrôle d'accès plus précis pour les mises à jour au niveau du champ, vous devrez actuellement l'implémenter dans votre API ou votre code d'application.
Il y a quelques demandes de fonctionnalités pertinentes que vous voudrez peut-être regarder/voter dans l'outil de suivi des problèmes MongoDB :
- SERVER-648 :contrôle d'accès au niveau du document
- SERVER-27698 :Vues matérialisées
