Using two business cards in the same composer rest

I did the tutorial to deploy to a multi org fabric network and it worked successfully .

Now i have two admin cards - alice@trade-network , bob@trade-network

and two identities/cards issued by them - jdoe@trade-network , dlowe@trade-network

Now i have given access control rules stating that jdoe (trader1-org1) and dlowe(trader2-org2) can only view their own records

Thus when i connect to their respective business cards i am able to view only their records . Now i can start two rest servers each (2 ports) for jdoe and dlowe which enables view of their records only through their rest api endpoints .

Now i know for a fact i can start another rest server for alice or bob who are admins so they can view all the records (jdoe's and dlowe's) But i dont want to do it that way . That is start a third rest server .

Is there any other way to achieve this . To get all the records in all cards ! Is there a way to start a rest server with two card instances or something like that .

Suggestions ?? Thanks~!

cool that you've been playing around with possibilities firstly.

The simple answer is to start a single REST server in multi-user mode, which enables wallets. See more here -> https://hyperledger.github.io/composer/latest/integrating/enabling-multiuser with an example of using Wallets (into which business network cards are stored). You can persist the wallet store to disk as described here -> https://hyperledger.github.io/composer/latest/integrating/deploying-the-rest-server.html

Then jdoe, dlow, alice and bob - as participants of the business network (each with their own business network card governed by whatever ACL rules are in place) - can interact using a browser client (REST API client) as the different participants (and therefore see different results as per your ACL rules).

There is an example of this in the Google OAUTH2 tutorial which shows how you switch identities, import a user's business network card / set it as default in the REST API, so that its using a specific blockchain identity / participant to perform activities on the business network (see specifically 'Step Eleven' onwards).