1

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:

  1. How does the Rest Server knows which wallet to use for a specific logged-in client?

  2. How to create channels and join peers from/using the Rest Server?

Thanks hackers!

José Pablo Orozco Marín
  • 364
  • 1
  • 6
  • 19

1 Answers1

2

  1. 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)

  2. 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.

Paul O'Mahony
  • 6,740
  • 1
  • 10
  • 15
  • Thanks a bunch and sorry to bug you. What if a second new user tries (or an existing one) to sign up to the app: Do I have to use the`/wallet/{name}/setDefault` endpoint in order to make the new user the signer of new transactions? If so, what happens if the first user was in that very concurrent time in the middle of their own transaction? is the transaction signed by the new authenticated user or… probably I am missing something very obvious here. Thanks! – José Pablo Orozco Marín Mar 14 '18 at 15:22
  • for new user - no, it will be its default identity automatically, once imported. See here https://hyperledger.github.io/composer/latest/tutorials/google_oauth2_rest (jdoe card is an example). If an app user, already with another imported identity/card - then yes, would have to `setDefault` to switch identity to the newly imported card (to then sign transactions, as that identity) – Paul O'Mahony Apr 27 '18 at 13:30