ECerts are not used in assign functions

[ghost]

Recipient roles in Invoke function are hard-coded in v0.6. ECerts saved in Init functions are not used to check recipient's affiliation. This means that I can assign an asset to any username because the certificate will not be checked.

Maybe it is ok for the demo, but in v0.5 certificates were used in assign operations. It was more secure.

[liam-grace]

We are using attributes to manage recipient affiliations now. We use an attribute called 'role' that is registered with the member service, and the chaincode checks if a user has the correct role or not.

[ghost]

Yes, I see it. But function Invoke passes hard-coded roles into assign functions. For example, t.authority_to_manufacturer(stub, v, caller, caller_affiliation, args[0], "manufacturer")

And inside authority_to_manufacturer condition recipient_affiliation == MANUFACTURER is always true. Does it mean that I can send any username in argument caller to this function and it will pass?

[liam-grace]

I see what you mean. The hard coded manufacturer and others like it will be changed to caller_affilliation, thanks for pointing that out

You will be able send any username as caller but only within the chaincode. When called from the application, caller is set in the Invoke method, using caller, caller_affiliation, err := t.get_caller_data(stub), which uses the username attribute

[liam-grace]

My previous reply is incorrect. The hard coded "manufacturer" is the recipients required role/affiliation. The recipient_affiliation == MANUFACTURER check is there so that is another role is specified, the function fails.

Regarding being able to pass any caller into the method, it will only work if that caller has the role attribute 'manufacturer'. These attributes are currently specified here

[ghost]

I meant recipient_name, not caller. That was a typo. Thank you for your answer.

[liam-grace]

Yes, there is currently no check to see if the recipient has the correct role, and the only way I can see that working would be to store a table of users and their affiliations and look it up when needed. For the demo, I doubt it is necessary.

[ghost]

In 0.5 you parsed recipient's certificate and got affiliation from it. Is there a problem to do it the same way in 0.6?

[liam-grace]

The in 0.6 tcerts are unlinkable to ecerts, meaning that we can't get any information from the certificates

[gelijie2hao]

hello ,After i click the button of Deploy to Bluemix,the project run successfully but when i change any code in bluemix ,the project can not deployed normally; can you tell me why?thank you very much!

[gelijie2hao]

and i want to know ,in this project ,The realization of the consensus of the nodes is virtual or real? Where can be reflected,Look forward to your reply thank you !

[liam-grace]

Hi @gelijie2hao, would you please create a new issue for this problem? The issue is that the application's certificate store is not persisted across application restarts, meaning that editing the code in bluemix isn't possible without breaking the demo. If you want to edit the code and deploy to bluemix, I recommend cloning the car-lease-demo repository and using Cloud Foundry to push to bluemix. Consensus is done between peers that you can see in the blockchain service you'll find on your bluemix dashboard.

[gelijie2hao]

Maybe my english is so poor that you understand difficulity ! thank you for your answer; i can't understand your recommend ; i try some ways to edit the code for example i clone done the zip,and edit the code locally,then submit my own repository and change the address of "Deploy to Bluemix" to mine,but deployed failed;would you please describe detailed? thank you so much