Mit Transaktionen können wir unsere Geschäftslogik in die Transaktionsprozessoren einfügen. Sehr einfache Zugriffskontrolllogik kann in die ACL-Datei eingefügt werden. Aber wie können wir komplexere Logik verwenden, um Abfragen zu schützen (oder zu erweitern)?Wie Logik bei Abfrage ausführen?
Ich arbeite an einem Fall, in dem ich den Lesezugriff auf ein Asset einschränken möchte, indem überprüft wird, ob ein anderes Asset existiert und eine bestimmte Eigenschaft hat.
Beispiel:
asset PersonalDetails identified by id {
o String id
o String dateOfBirth
o String firstName
o String lastName
--> Participant owner
}
asset AccessRequest identified by id {
o String id
o String property
o Boolean allowed
--> PersonalDetails personalDetails
}
Wenn ein Teilnehmer PersonalDetails anfordert, ein AccessRequest hat zu existieren und === wahr erlaubt zu haben. Der Inhaber der persönlichen Daten ist derjenige, der Zugang gewähren kann. Idealerweise besitzt das AccessRequest eine Feldeigenschaft, um eine feinkörnigere Zugriffskontrolle zu ermöglichen.
Also mein erster Gedanke war:
transaction GetInfo identified by transactionId {
o String transactionId
--> AccessRequest accessRequest
}
/**
* Sample transaction
* @param {org.example.GetInfo} tx
* @transaction
*/
function getInfo(tx) {
if (!tx.accessRequest.allowed) {
throw 'Access denied.';
}
return Promise.resolve(tx.accessRequest.personalDetails[tx.accessRequest.property]);
}
Aber ich glaube nicht, Composer unterstützt Werte aus einer Transaktion zurückkehrt (rechts?). Also, wie können wir im Allgemeinen die Logik in oder vor Abfragen verwenden und genauer gesagt, was wäre der "kompositorische Weg", um meinen Fall zu lösen?