Hyperledger Composer - Как запретить участнику изменять определенные атрибуты своего ресурса, если у него есть разрешение UPDATE в acl?

Question

Я кодировал систему представления статей в компоновщике hyperledger, которая должна в основном позволять участнику типа «Автор» создавать ресурс «Статья», который должен проверяться рецензентом (другой атрибут «Автор» isReview = true).

Вопрос в том, что, следуя логике ACL, Автор может изменять свои данные, и это включает атрибут, который определяет, являются ли они рецензентом.Этого нельзя допустить, потому что автор становится рецензентом только тогда, когда он успешно публикует статью.

Мой вопрос заключается в том, нужно ли мне каким-то образом ограничить это в логике javascript hyperledger или я могу замаскировать это вклиентское приложение, если оно может быть выполнено на клиенте, может ли хакер использовать этот «пробел»?

Я знаю, что могу сделать это в клиентском приложении, но я не знаю последствий этоготакой подход, поскольку все системы должны работать на серверной стороне из-за проблем безопасности.

.cto

participant Author identified by email {
  o String authorId optional
  o String email
  o String firstName
  o String lastName
  o Boolean isReviewer default=false
  o Double points default=0.0
  o Double reputation default=0.0
}

.acl

  rule AuthorCanUpdateData {
      description: "Allow all author access to all resources"
      participant(m): "org.dasp.net.Author"
      operation: ALL
      resource(v): "org.dasp.net.Author"
      condition: (v.getIdentifier() == m.getIdentifier())
      action: ALLOW
  }

Iнадеялся определить, какой атрибут объекта участник может изменить или нет.но я не нашел ничего из этого, просто ЧИТАТЬ, ОБНОВИТЬ, СОЗДАТЬ И ВСЕ

Answer 1

Hyperledger Composer не имеет элементов управления авторизацией «уровня атрибута», он в основном контролирует, у каких участников есть ограничения на какие ресурсы (класс, экземпляры (и) и т. Д.) В бизнес-сети.

Итак - на вопрос: если вам нужен контроль уровня атрибута (а «автор» обращается к бизнес-сети через клиентское приложение) - тогда да, вы должны реализовать клиентскую часть.Здесь применимы обычные проблемы безопасности (извините, я не могу помочь вам, кто должен иметь доступ к вашей бизнес-сети от клиента, какие организации / коллеги должны одобрить транзакции и т. Д. И т. Д.).

Что касается ограничений в рамкахВ бизнес-сети, кажется, вопрос вкратце: «Могу ли я запретить неопубликованному автору изменять его статус isReviewer специально?»

Да, вы можете ограничить это, поддерживая отдельный список активов статуса в этом случае.:

participant Author identified by email {
o String email
o String authorId optional
o String firstName
o String lastName
o Double points default=0.0
o Double reputation default=0.0

}

asset Authorship identified by authorId {
      o String authorId 
      o Boolean isReviewer default=false
    }

тогда ваш ACL (как он есть) будет работать («автор может редактировать свой профиль»), так как вы работаете на уровне ресурсов и вашклиент может проверить статус рецензента (если это то, что он в данный момент делает, т. е. имеет ли кто-то полномочия на рецензирование).