In the client applications (using Node/Go) we provide connection profile to identify the endpoints of endorsers.
There we specify endpoint of peer in terms of grpc://localhost:port but actually gRPC runs on HTTP2 right?
Then does the Fabric SDK convert the endpoint to a HTTP url or is it handled by fabric peer code?
I mean how is grpc endpoint converted to an HTTP one?
Or does the peer expose a grpc endpoint itself? If yes, how?
For communicating between the front-end and the Hyperledger Fabric Layer, we have two ways, one to use the gRPC calls OR use one of the SDKs provided by the Hyperledger Community. There are no REST API calls after v1.0, as opposed to v0.6, which had REST API calls, where you could use the IP Addresses to fire transactions to the Orderer, then Consensus.
Making it limited to gRPC and SDKs improves the design and connection security issues, which is vital for the Blockchain to work. gRPC is the HTTPS 2.0 protocol for communication which is faster and has improved security features over HTTPS 1.1. SDKs use gRPC calls to communicate to the network. So, putting it plainly, if you need to communicate with the Network, you need to use gRPC calls only
As suggested by #david_k in comments above, the URL in connection profile is used for extracting the host and port number after identifying whether it is grpc or grpcs (over SSL) call.
To verify:
Deploy the fabcar sample and install the node modules.
Go to the Endpoint.js file in the fabric-common node module inside the lib directory. Edit the line corresponding to line 44 here.
Go to the first-network directory (the network used by fabcar sample) to edit the connection profile. Replace the grpcs in the peer and orderer URL corresponding to the edit you made to the Endpoint.js file in node modules.
Return back to the javascript directory and fetch the wallet identities.
Modify the invoke.js to read the new connection profile.
Execute it to see that the transaction is submitted successfully.
Therefore, we can identify that only the host and port are fetched from the URL to be used for making a grpc/grpcs call to the fabric network.
Related
While it is possible to use Nodejs's fabric-ca-client to perform enrollment through a REST API, this requires communication with a third party service which could compromise security as the end user's secret must be shared.
Is there a way to interact with the fabric through the web directly, bypassing the need for a REST API to ensure security? Attempts at using browserify and webpack to bundle the fabric-ca-client module have been unsuccessful as the necessary modules cannot be found or are incompatible.
Is there something crucial that I am missing in this approach? Any recommendations for secure enrollment applications for the client in other languages or architectures, such as Android applications, would be greatly appreciated.
Thank you.
fabric-ca server is not mandatory for a fabric network. You can use alternative CA services to issue private keys and certificates so long as you create the appropriate MSP definition for your organisation which could be one option for you.
fabric-ca server already supports REST style requests, all fabric-ca-client node.js module does is wrap those calls into an easy to use interface for node.js applications. It should be possible to write a mobile phone application or web based application to interact with directly with a fabric-ca-server. It may be that is how the fabric operations console in hyperledger-labs actually does it as it doesn't bundle fabric-ca-client but can still interact with fabric-ca-servers.
You will probably have to inspect the fabric-ca-client code or fabric-operations-console code to work out how it does this as the fabric-ca documentation doesn't appear to describe the interfaces to do this.
I saw a lot of references to grpc and client interactions with http2 to the endorser. I have also seen some references to rest api. My confusion is that with so many versions now from 0.6 to 2.2 I am getting confused on the actual protocol standard from the client to the endorser.
If I have 2.0, is everything using grpc which implements the api from the client to the endorser via http2 and the sdk?
There are four primary APIs used for interactions between the Fabric SDK Client and the Fabric peers and orderers. These services are all gRPC based.
The peer exposes a Propose rpc, a Discover rpc and a Deliver rpc. The Propose rpc is responsible for producing endorsements which are bundled by the client into a transaction. The Discover rpc is used to help a client understand which peers a proposal could and or should be endorsed by. The Deliver rpc is used by the client to consume blocks as they are committed and detect transaction commitment.
The orderer exposes a Broadcast and Deliver rpc. The Broadcast rpc accepts transactions to be included into the blockchain, and the Deliver rpc provides blocks (usually to peers, but sometimes to clients as well).
There are some other components in the system which provide other APIs -- the operations endpoints meant for health checks and metrics, for instance use REST. But, these components are typically not consumed by a client application.
In comopser rest server I know its advisable to store network card with composer rest server. Now what if I dont want to store my network card in rest server wallet. How to sign transaction indvidually by passing my certificate during calls to rest server.
You can use Cloud-based wallets see -> https://hyperledger.github.io/composer/next/business-network/cloud-wallets available from v0.18.x onwards
You can use the Composer JS APIs to connect to the business network with a business network card, and then transact on the network, as that blockchain identity. Example here -> https://github.com/hyperledger/composer-sample-networks/blob/master/packages/pii-network/test/pii.js#L119 onwards (instead of MemoryCardStore shown here, you can use FileSystemCardStore to work with a card in your wallet store)
See also Hyperledger Composer Web application user authentication for more information
I was reading this pretty cool article this morning:
https://medium.com/#CazChurchUk/developing-multi-user-application-using-the-hyperledger-composer-rest-server-b3b88e857ccc
I am interested in the Rest Server features but I have a couple of questions on it:
How does the Rest Server knows which wallet to use for a specific logged-in client?
How to create channels and join peers from/using the Rest Server?
Thanks hackers!
Once a REST client (where the wallet is) has authenticated to the REST Server, that client can add Blockchain identities (one or more) to its own REST client wallet. The wallet is private to that client, and is not accessible to other clients. When a client makes a request to the REST server, a Blockchain identity in the clients wallet is used to digitally sign all transactions made by that client (and the REST server knows who that is on the business network as that identity is mapped to a participant).
Please note that this feature requires that clients trust the REST server. This trust is required because this feature requires that the REST server stores the clients Blockchain identities as part of the card. Therefore, it is strongly recommended that clients only use REST servers that are managed by a trusted party, such as an administrator within their organization.
All information regarding authenticated users and their wallets (containing each users business network cards when multiple user mode is enabled) is persisted in a LoopBack data source by using a LoopBack connector. You would normally set up a persistent store such as MongoDB and the REST server would use a Loopback adapter to access the MOngoDB store. REST clients that have authenticated via a strategy will normally get an access token (once they authenticate) and which is stored locally (such as in the browser for OAUTH2)
Channels and Peers (which come from Hyperledger Fabric) are configured in connection profiles (connection.json file) which are part of the business network cards built for a participant of the business network. The REST server itself doesn't 'join peers or channels' it knows about it because it is started with a business network card (and the definition of the channel and peers are known to the REST server that discovers the business network to which it relates). Obviously you can stand up many REST server instances to serve the different 'living' business networks deployed (on whatever channels (ledgers) or peers defined in the profile) in an organisation.
I am working on a REST API to be used by a mobile application I am writing, mostly for the purpose of communicating with a database.
The mobile application makes calls to URLs like this:
example.com/mobileapi/getinfo
And carries certain POST payload along with each call.
I'm not worried about user authentication etc.
However, what I am worried about is, if someone were to use the mobile application along with a network monitoring tool like Fiddler or Wireshark, they could document all the URLs being called, along with all the POST parameters. That would be enough information to create their own app that uses my API.
How can I prevent this? I considered hardcoding a Key into my application and have that included as a POST parameter with each request, but that would be visible as well.
What you want to do is employ mutually-authenticated SSL, so that your server will only accept incoming connections from your app and your app will only communicate with your server.
Here's the high-level approach. Create a self-signed server SSL certificate and deploy on your web server. If you're using Android, you can use the keytool included with the Android SDK for this purpose; if you're using another app platform, similar tools exist for them as well. Then create a self-signed client and deploy that within your application in a custom keystore included in your application as a resource (keytool will generate this as well). Configure the server to require client-side SSL authentication and to only accept the client certificate you generated. Configure the client to use that client-side certificate to identify itself and only accept the one server-side certificate you installed on your server for that part of it.
If someone/something other than your app attempts to connect to your server, the SSL connection will not be created, as the server will reject incoming SSL connections that do not present the client certificate that you have included in your app.
A step-by-step for this is a much longer answer than is warranted here. I would suggest doing this in stages as there are resources on the web about how to deal with self-signed SSL certificate in Android (I'm not as familiar with how to do this on other mobile platforms), both server and client side. There is also a complete walk-through in my book, Application Security for the Android Platform, published by O'Reilly.