How should I allow external application users(that do not run nodes on the network) to allow using an hyperledger fabric app ? How are the identified in the network ?
You could provide a REST API as the gateway to the blockchain network. Depending on how much you want to lock down functionality, you could refine the REST URLs to divert to different users in the wallet so that perhaps some might have read only access and others might have higher levels. You can set up the contract code to recognise which user is currently trying to perform an action and take steps to restrict them more. It all depends on your requirements. The external users could be given access to URLs specific to their organisations which would seek to access blockchain through a wallet dedicated to such an organisation. Therefore, there is no possibiity of crossover with other orgnisations.
If you are developing using Node.js, it is very easy and quick to set up an example REST API using Express.
Related
I am trying to implement a tamper proof uncentralized database of some records. these record are static and they cannot be transferred between participants, i.e, not like some currency or a stock. i just want them to be stored as they are. Identity is an important thing with my project. only certain people can add blocks to the chain, rest of them should be only there to verify the chain. Can i implement a blockchain for this usecase? if it is possible should i use an ethereum chain or hyperledger fabric?
According to your use case which is, certain people, add records and certain query records. A typical normal access control application and the database can solve your issue but,
If you deal with untrusted people and need complete transparency with identity-based access control and equal rights of all participants then hyperledger fabric is best.
Every time an Id is issued to a participant in hyperledger, a card gets generated and imported to the network. by default imported card gets stored in home/.composer/cards directory. So, anyone having access to machine can have access to those cards. Similar with the case when cards get stored on the cloud storage. Is there any provision in hyperledger to restrict the access to those card?
No there isn't. You need to choose the appropriate way for you for storing cards and secure that location in whatever way you deem necessary. As you have seen there are various cloud wallets to provide alternative locations of storage, but you can also develop your own cloud wallet which meets your needs if required.
Examples of cloud wallet implementations can be found at
https://github.com/hyperledger/composer-tools
For the usecase of a market place where users buy and sell stocks, which kind of nodejs architecture for hyperledger-composer should be adopted
for hyperledger Fabric where users dont trust the system. I read many blogs where they said to maintain the cards of user in their
local system.
If i follow UI + Middleware + FabricRuntime. where should the card management be provided and which part/layer should be exposed to user.
Could you please suggest how the design of application must be for such kind of usecases?
I am new to composer, and now practicing some of the tutorials and examples. But while doing this I can not understand some of the features, so here are the questions which I do not clearly understand:
Are queries restricted by .acl file (when, for example, we use them in rest server)?
Do the rules written in the .acl restrict some of the transactions which are allowed for certain participant to submit? (For example, for participantA it is not allowed to CREATE new participants, but what happens if participantA submits the transaction(which is allowed for him to submit)which creates another participant, will this transaction fail?
Could cards be created by rest api server?(I know that participants could be created using JS api, but is it possible to create and issue the identity for those participants through RestServerApi?)
What happens when PeerAdmin upgrade certain node to a new version? How do other nodes act in this case? Do they upgrade themself automaticly?(Also found that upgrade takes a lot of time(2-4 minutes) when deployed locally, whereas in browser for local connection it takes 3-4 seconds)
Does Hyperledger fabric allow some of the ledger data be stored in one private network, whereas other network connected to the private one would not store this part of ledger( or the data will be simply crypted)? The same question regarding the transactions: will the be executed on outer networks?
Yes Composer Queries (and therein, results) are subject to ACL restrictions or filters.
It will still fail due to ACL rule restriction. Once denied to create, always denied as that is the final operation (in this scenario). The actual transaction would fail.
Yes of course use POST /system/identities/issue REST endpoint (eg http://localhost:3001/api/system/identities/issue) - see an example here -> https://medium.com/#CazChurchUk/developing-multi-user-application-using-the-hyperledger-composer-rest-server-b3b88e857ccc
An administrator with PeerAdmin capability has responsibility to install new version on his peers (in his Org). The other Org peer Admins are responsible for theirs, that's how a blockchain consortium with different Orgs will work. They will agree the 'what' and when but will need to install the new version on own Org's peers, so the new version can be started on the same channel. Of course, there will be a difference between a Fabric infrastructure response time, and that of a web connection using local storage.
Channels in Fabric implement privacy. You can have one or more business networks on that channel (ledger), therefore transactions in that business network are private to that ledger. It is the client's responsibility to encrypt data or not. Hyperledger Composer can allow call one business network from another, on the same channel, or if permitted to do so, on different channels too - see https://hyperledger.github.io/composer/latest/tutorials/invoke-composer-network
We are currently looking into implementing Stripe Connect to process payments on a multi-tenant platform. On this platform, each tenant has an own instance of our web application with their own database and their own domain. The deployment is triggered by the client’s online registration and fully automated, so we don’t know in advance when there will be a new application instance.
While this setup doesn’t seem to be a problem in general, we are facing problems with Stripe’s requirement to hardcode several URLs into Stripe’s dashboard, especially the webhook URLs and the return URL for the onboarding workflow. This does obviously not work for us, as we would add the URLs for each domain of our clients.
Is there a way to set these URLs through an API for each tenant or (in regard to webhooks) for a single transaction? Or is there some other way that might work in our scenario?
There is no way set these dynamically but there are workarounds if your instance separation allows it.
For the OAuth flow and the redirect URL you can have a generic URL in your own domain that handles the connection and then redirect to their domain afterwards based on a parameter or the session.
For the webhooks since you're using Connect you can actually receive all the events of the connected accounts in your platform directly:
https://stripe.com/docs/connect/webhooks
The drawback is that you'd need a way to notify their instances that something happened if you need the data stored in their separate databases (or you could handle it locally since you own the full server)