Hyperledger Composer - правило ACL с функцией в состоянии - PullRequest
Новая
       5

Hyperledger Composer - правило ACL с функцией в состоянии

0 голосов
/ 19 мая 2018

Я пытаюсь написать более сложную логику в условии правила ACL, как всегда p.getIdentifier() == r.getIdentifier(), потому что по моей вине это невозможно.

Это мои модели: 

participant Customer identified by customerID {
  o String  customerID
  o String  name
  ...
}

asset A identified by aID {
  o String       aID
  --> Customer   customer
}

asset B identified by bID {
  o String  bID
  --> A     a
}

Теперь я хочу дать Customer доступ к просмотру всех B активов, но только там, где отношение к A ссылается на актив, который имеет фактическое участие Customer, который "вошел в систему".

Обобщенная логика: от актива B до A, а затем от A до Customer.

Так что в этом случае яне может сравнивать идентификаторы Customer и B напрямую, и им нужно перейти на A.Поэтому я хотел проверить доступ с помощью функции, которая вызывается в файле script.js: 

rule CustomerAccessCustomer {
  description: "The customer should see all B assets, but only when he have a relationship in asset A "
  participant(p): "org.xxx.test.participant.Customer"
  operation: READ
  resource(r): "org.xxx.test.asset.B"
  condition: (evaluateAccess(p,r))
  action: ALLOW
}

Вот функция script.js: 

async function evaluateAccess(p,r) {
  try {
    const bRegistry = await getAssetRegistry('org.xxx.test.asset.B');
    const b = await bRegistry.get(r.getIdentifier());

    const aRegistry = await getAssetRegistry('org.xxx.test.asset.A');
    const a = await aRegistry.get(b.a.getIdentifier());

    if (p.getIdentifier() === a.customer.getIdentifier()) {
        return true;
    }
  } catch (error) {
    console.log(error);
  }
}

Но яполучаю ошибку Error: The runtime API is not available.

Думаю ли я, что неправильно, нельзя ли оценить доступ с помощью функции?Как вы справились с правилом доступа, если не можете просто сравнить идентификаторы?

Ответы [ 2 ]

0 голосов
/ 21 мая 2018

вы просто должны быть в состоянии сделать: 

rule CustomerAccessCustomer {
  description: "The customer should see all B assets, but only when he have a relationship in asset A "
  participant(p): "org.xxx.test.participant.Customer"
  operation: READ
  resource(r): "org.xxx.test.asset.B"
  condition: ( (p.getIdentifier() === r.a.customer.getIdentifier()) 
  action: ALLOW
}

, но p также потребуется доступ к READ, чтобы иметь возможность «прочитать» ресурсный ресурс «A» (для проверки идентификатора и т. Д.) Впервое место: -)

0 голосов
/ 19 мая 2018

Клиент должен быть участником, а не активом: 

participant Customer identified by customerID {
  o String  customerID
  o String  name
}
...