HyperledgerHandsOn/trade-finance-logistics

Instructions in ABAC.md not working with regards to changing calling identity from CLI

Opened this issue · 4 comments

Hull4Progress commented

I am working with release-1.4, and focused on ABAC, using the ABAC.md page, specifically https://github.com/HyperledgerHandsOn/trade-finance-logistics/blob/release-1.4/chaincode/abac.md

I am running in dev mode as per Chapter 4 in the book. I believe that I am faithfully following the instructions about running " /opt/trade/createIdentity.sh" in the cli container.

However, when I attempt to invoke a trade request from the cli, presumably with the identity of "admin", it turns out that the creatorOrg, creatorCertIssuer are 'DevOrgMSP' and 'ca.devorg.trade.com'.

If I execute "export CORE_PEER_MSPCONFIGPATH=/root/.fabric-ca-client/importer" in the CLI and again invoke a trade request, it turns out that again the creatorOrg, creatorCertIssuer are 'DevOrgMSP' and 'ca.devorg.trade.com'.

Do you have any ideas what I am doing wrong or missing?

BTW, another small question is: If I follow your instructions using trade_workflow_v1, and then on page 106 I perform the two invoke steps, it turns out they are executed in test mode. But if I make a slight edit (or no edit) to tradeworkflow.go in my local machine and upload into the chaincode container and re-build go and etc, and then I perform the invoke steps, they are NOT in test mode anymore. How are you magically having it start in test mode the first time, but not after re-loading tradeworkflow.go.

Thanks

ldesrosi commented

@Hull4Progress, I will need to have a look at it. I don't believe this process was re-tested for 1.4. I'll aim to give you an update early next week.

Thanks

ldesrosi commented

@Hull4Progress I have been able to re-test the ABAC instructions and now re-reading your post I understand.

When starting the network in dev mode, it contains a single organisation: DevOrgMSP (With the CA ca.devorg.trade.com). You can see that in the configtx.yaml from the folder network/devmode/configtx.yaml. As such, any identities can only be issued from this organisation.

Because the network only has the DevOrgMSP organisation, you need to ensure that the chaincode testMode is set to True. This will avoid the chaincode invocation from performing checks on the type of org (Importer, Exporter, etc...).

The ABAC instructions will make you test the modified chaincode with two identities:

  1. admin identity of DevOrgMSP, which should generate this message in the chaincode session: Custom attribute tradelimit was not found.
    The client-side should see an error message because the amount is above the default limit.
  2. Importer identity of DevOrgMSP, which should generate this message in the chaincode session:
    Custom attribute tradelimit was found with value 1000
    The client-side should see a success message because the amount is below the default limit.

Looking at the createIdentity.sh script, I can see how it can confuse: The script is setting the enrollment id to importer and storing the resulting MSP data in a folder also called importer, but since it is issued from the fabric-ca server of DevOrgMSP, it belongs to that Org and not to Importer. Apologies for that confusion.

On the final point, regarding the chaincode not remaining in dev mode, I took a look at the latest behaviour of 1.4. Upon doing a docker inspect chaincode, I have noticed the following startup code in the container image:

cp -r /opt/gopath/src/chaincode_copy/* /opt/gopath/src/chaincode/

This means that any changes to the source code on the file system are ignored because the dev chaincode is working on a copy. I suspect that is what is happening when you subsequently modify the chaincode code and do not see it reflected.
Before running go build in the chaincode container session, I would suggest that you run the cp command above to see if your code changes are now taken into account.

Let me know if that makes sense and if you have any further questions.

Hull4Progress commented

Luc - thank you very much for these comments. I have been able to make everything work.

As a small point for other readers, with regards to transferring new code modules into the chaincode container, it is also important that the code be loaded from one's local machine into chaincode:/opt/gopath/src/chaincode_copy/..., rather than into chaincode:/opt/gopath/src/chaincode/...

As another small point, I see in the createIdentity.sh there are lines at the bottom that copy the importer/signcerts into importer/admincerts. This enables a CLI command that switches context over to the importer user. I have found it convenient to also add lines that copy the admin/signcerts into a new directory admin/admincerts. This lets me to easily shift back and forth between the importer and admin users from the CLI using the "export CORE_PEER_MSPCONFIGPATH=/root/.fabric-ca-client/" command.

(BTW, are you aware that in the README part of the page https://github.com/HyperledgerHandsOn/trade-finance-logistics/tree/release-1.4/network there are some typos, in particular, where release "1.2" is mentioned it should really be release "1.4".)

Thanks very much again
Rick

VRamakrishna commented

Thanks @Hull4Progress . Fixed the version typos on the page you've linked to above.