How to get information about the party that started transaction in contract code (verify)? That would be useful for implement checks like "only owner of the input state can do some action" in contract instead of flow.
Thanks. Sorry for my bad English.
This information is not contained in a Corda transaction, and therefore cannot be checked by the verify method.
Instead, you should make the owner of the state a required signer, and they should only sign if they are willing to authorise the transfer.
Additionally, you may want to put a check like the following in your flow to prevent human error:
check(ourIdentity == lenderIdentity) {
"Obligation transfer can only be initiated by the lender."
}
Related
In my SignalR hub, I use the following method to check whether a user has an active connection:
var receivingClient = Clients.User(receiver);
if (receivingClient != null)
{
But I also track the online users manually over OnConnected \ OnDisconnected (in a ConcurrentDictionary). Now even when I shut down everything and start the server from scratch (e.g. IISExpress from VS), the above code part returns a result for a connection that doesn't exist.
Let's say I send from User A to user B. I start the server, go online with user A, then send a message to B: The above code returns a Microsoft.AspNetCore.SignalR.Internal.UserProxy<mySite.Services.ChatHub>.
I don't get it. Is it wrong to check for existing client connections with a null check? Should I exclusively rely on my manual tracking?
Thanks for some insight!
(PS: This is all on the same server - no load balancing / sharding)
Clients.User(receiver) returns a type that is used to invoke methods for the given user. It doesn't have anything to do with whether the user you pass in exists or not.
Is it wrong to check for existing client connections with a null check? Should I exclusively rely on my manual tracking?
Yes. Use manual tracking.
Regarding CollectSignatureFlow with accounts:
In the comments of worldcupticketbooking's file: DVPAccountsOnSameNode
its given Note: though buyer and seller are on the same node still we will have to call CollectSignaturesFlow as the signer is not a Party but an account.
But here its said that If your accounts are on the same node that you are running the flow on then they can all be on the signInitialTransaction, however, if one is on another node you need to use a CollectSignatureFlow
I disagree with the comment from the DVP CorDapp that you shared; if all required signers exist on the initiating node, there's no need to call CollectSignaturesFlow, instead just pass the keys of the accounts like below:
getServiceHub().signInitialTransaction(transactionBuilder,
Arrays.asList(getOurIdentity().getOwningKey(),
account1Key, account2Key, account3Key, etc...));
First, thanks Hasura for incredible good product! I love it.
I have issue with derive action with Hasura Console. My use case:
I enable anonymous role for subscribe function (everybody can send email to subscribe)
I have configured permission on my subscribe table, everything is fine.
I want to validate the user input on server side, for example, validate email format. I have followed by this guide about derive action. I found no mistake here.
But I got the error "Type query_root must define one or more fields." when I hit "Derive action" at the first time.
According to this question, as I understand, I need to have object type for root query.
Of course, I will have object type for root query eventually. I can work around by giving some dummy queries for anonymous role. But I do not like that cheat anyway.
Any idea on that? Any help will be highly appreciated.
Edited:
My related current version:
Hasura 1.3.2
One click deployment using Docker on Digital Ocean.
Is the contract handling code essentially just Java and run by the server ?.
If I want to edit a contract's functionality do I have to release code to be installed across the network ?.
Great question. The Corda technical whitepaper talks about this. See e.g. section 5.9: https://docs.corda.net/_static/corda-technical-whitepaper.pdf
The short answer is that some of this infrastructure still needs to be built out but the key idea is that a State doesn't just say "the Java class with this name governs my evolution"; it says: "the Java class with this name, living in a JAR with this hash governs my evolution". So there will be no room for games caused by people trying to substitute malicious/compromised implementations.
As for how the code gets distributed: today, it is installed in each node locally. Very soon, it will be able to migrate around the network using the Attachments functionality.
And I should add: the contract verification logic will run in a very strict sandbox: both to limit what it can do and to ensure it is 100% deterministic... we can't have one node thinking a transaction is valid and another one thinking it is invalid!
As Richard notes, states reference contracts. Indeed, there is a contract property in the base ContractState interface:
#CordaSerializable
interface ContractState {
val contract: Contract
val participants: List<AbstractParty>
}
A Corda transaction is required to change any state property. Therefore, if one party wishes to novate/update the contract code then they must propose a transaction which changes the contract reference then ask all required participants to assent to this change.
I would like to add a new Notary/Regulatory node in my Cordapp application ,
which should perform some extra validation checks when transaction
is completed between two parties.
so that notary/regulatory will be finally checks for some things and stamp the transaction.
There are two options here:
Instead of using the default FinalityFlow to notarise, broadcast and record transactions, you can implement your own flow that performs some additional validation before the notarisation step. The limitation here is that the checks are not part of the notary service.
Create your own custom notary. Here, the custom validation checks happen within the notary service. The ability to do this is a recent change to the codebase, as such the documentation has not been updated to reflect the changes, however the source docs can be found on github:
Instructions for creating a custom notary service: https://github.com/corda/corda/blob/9e563f9b98b79a308d68ecb01c80ce61df048310/docs/source/tutorial-custom-notary.rst
Sample custom notary service code: https://github.com/corda/corda/blob/9e563f9b98b79a308d68ecb01c80ce61df048310/docs/source/example-code/src/main/kotlin/net/corda/docs/CustomNotaryTutorial.kt
As Roger notes, you could customise FinalityFlow/implement your own notary.
An alternative would be:
Add a new node to the network representing some regulator
Write the contract rules so that the regulator is a required signer on transactions
Have the regulator do additional checking of the transaction in their flow before signing