feat: Supply-chain with wallet authentication #3914
Conversation
Eajunnn
requested review from
TheJagpreet,
VRamakrishna,
izuru0,
outSH,
sandeepnRES and
takeutak
as code owners
|
I created a whole new supply-chain workflow by adding wallet authentication, using sepolia testnet as ethereum network for testing. All endpoints now are in fabric. Public data stored in sepolia while private are in fabric. User can see certain information based on their connected wallet role. I also created a payment endpoint where it uses sepolia to pay the shipment. If you guys wanted this as additional 3 examples of supply chain in that examples directory can just put all these as new 3 folders in examples directory instead of merging into the original ones. The original ones are using besu and xdai preset testing account, but this is more real world approach. Thanks |
There was a problem hiding this comment.
It all looks great, although I've left some high level comments to be addressed first.
Additionally, please update the PR and commit to match our contributors guide (https://github.com/hyperledger-cacti/cacti/blob/main/CONTRIBUTING.md). In particular:
- Name of the commit and PR should be something like (feat(supply-chain): add wallet authentication (the key thing is to include in paranthesis after feat).
- Squash all commits in this PR into single one.
- Include a signoff in your commit.
- Add description to the commit and PR body.
- (optional) Create an issue where you describe and justify feature shortly, then link to it in PR body by including
Closes: #XXXXwhere XXXX is number of your issue.
| "dependencies": { | ||
| "@angular/animations": "17.3.0", | ||
| "@angular/cdk": "17.3.0", | ||
| "@angular/common": "17.3.11", | ||
| "@angular/core": "17.3.11", | ||
| "@angular/forms": "17.3.11", | ||
| "@angular/material": "17.3.0", | ||
| "@angular/platform-browser": "17.3.11", | ||
| "@angular/platform-browser-dynamic": "17.3.11", | ||
| "@angular/router": "17.3.11", | ||
| "@hyperledger/cactus-plugin-ledger-connector-ethereum": "workspace:^", | ||
| "@metamask/detect-provider": "^2.0.0", | ||
| "ether": "^0.0.9", | ||
| "ethers": "6.13.5" | ||
| } |
There was a problem hiding this comment.
There should be no dependencies in root package.json file
| "devDependencies": { | ||
| "@types/express": "5.0.1", | ||
| "@types/uuid": "10.0.0" | ||
| "@types/jest": "^29.5.14", |
There was a problem hiding this comment.
Please pin the dependencies version (i.e. 29.5.14). We use pinned versions to prevent supply chain attacks.
There was a problem hiding this comment.
This applies to all package.json affected by this PR
| const ethereumConnector = new PluginLedgerConnectorEthereum({ | ||
| instanceId: "PluginLedgerConnectorEthereum_Sepolia", | ||
| rpcApiHttpHost: SEPOLIA_RPC_ENDPOINT, | ||
| logLevel: "DEBUG", | ||
| pluginRegistry, | ||
| }); |
There was a problem hiding this comment.
We don't want to force users to have access to sepolia node, through Alchemy or any other provider, to run the test application. Is it possible to make the sample app run on local ethereum network by default? Running on Sepolia could be an optional way of testing the application (must be well documented), but the default should work without much additional setup.
I think you can run geth-all-in-one (tools/docker/geth-all-in-one/README.md) the same way we run besu right now, and deploy and use all the necessary contracts there, or even use besu as sepolia alternative for local run. Please investigate which option suits you better :)
There was a problem hiding this comment.
Maybe I can make the sepolia approach optional by checking if they inserted in the process.env? If not it will just go through the original process (Besu and Xdai)? Because now I changed all to Sepolia and Fabric only. Or you guys wanted this to be another directory in examples?
There was a problem hiding this comment.
That works :) For me it's good to keep it single place, unless other maintainers have other opinion on it
|
@Eajunnn we are cleaning up merge requests that are stale. Please rebase, address comments, and solve conflicts so we can incorporate your contribution onto main. Thank you! |
3 participants
Pull Request Requirements
upstream/mainbranch and squashed into single commit to help maintainers review it more efficient and to avoid spaghetti git commit graphs that obfuscate which commit did exactly what change, when and, why.-sflag when usinggit commitcommand. You may refer to this link for more information.Character Limit
A Must Read for Beginners
For rebasing and squashing, here's a must read guide for beginners.