J'ai essayé de restreindre l'accès en désactivant la capacité d'une organisation à appeler le code de chaîne via: peer / Proposer: / Channel / Application / MyPolicy où
MyPolicy: Type: Signature Règle: "OR ('Org1MSP.admin')"
Mais cela empêche également Org2 d'interroger. Est-il possible pour Org2 de simplement interroger sans pouvoir appeler?
3 Réponses :
Non. Tout membre d'un canal peut interroger et appeler les codes de chaîne instanciés.
La seule chose que vous pouvez limiter est la Politique d'approbation < / a> - "qui spécifie l'ensemble des pairs sur un canal qui doivent exécuter le chaincode et approuver les résultats de l'exécution pour que la transaction soit considérée comme valide "
Vous pouvez atteindre cet objectif en restreignant l'accès aux fonctions dans le code de chaîne lui-même. Avec CID Lib , vous pouvez identifier les pairs appelants ( par exemple par leur msp) et gérer l'accès en fonction de ces informations. Avec cela et le concept d'AttributeBasedAccessControl, vous pouvez parfaitement gérer tous les accès aux requêtes / invocations sur la chaîne et les séparer au niveau des pairs et de l'organisation
Toutes les organisations d'un consortium ont la même autorité sur les données. Il n'est donc pas possible de donner uniquement un accès en lecture à une organisation. Si vous voulez vraiment le faire, que diriez-vous d'utiliser des données privées? Faites de toutes les données des données privées et autorisez toutes les organisations à l'exception de celle qui est victime d'intimidation.
Un moyen plus pratique serait de leur donner un serveur CA intermédiaire et de ne donner qu'un accès LECTURE à cette chaîne de confiance.
Pouvez-vous expliquer comment fonctionne la chaîne de confiance du serveur CA intermédiaire? De plus, si je rend les données privées, l'organisation victime d'intimidation ne pourra pas lire aussi bien, n'est-ce pas?