Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: restrict token registry to fail on multiple issuers #129

Merged
merged 7 commits into from
Oct 30, 2020

Conversation

yehjxraymond
Copy link
Contributor

@yehjxraymond yehjxraymond commented Oct 30, 2020

Having stricter check with token registry to disallow matching it with other identity verification types.

  • verifier to fail if its not ONE issuer that is using tokenRegistry.
  • refactored catch-all error handler to be used across all verifiers. simply use withCodedErrorHandler to wrap verify function and throw know errors with CodedError.

options: Parameters<Verifier["verify"]>[1]
) => {
try {
// Using return await to ensure async function execute in try loop
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// Using return await to ensure async function execute in try loop
// Using return await to ensure async function execute in try block

network: string;
}): Promise<{ minted: boolean; reason?: string }> => {
try {
const tokenRegistryContract = await TradeTrustErc721Factory.connect(tokenRegistry, getProvider({ network }));
Copy link
Contributor

@Nebulis Nebulis Oct 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • why getting rid of code and codeString ? that makes it a breaking change ... and harder to deal if want to handle specific errors
  • why getting rid of SERVER_ERROR ? We use it on opencert to differentiate a business and a technical error

Copy link
Contributor Author

@yehjxraymond yehjxraymond Oct 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I knew you will ask, which is why i got you to review.

For the errors which this verifier knows for sure that the result is either true or false, it returns that.

For errors which it is uncertain if the document is issued or not, it will throw.

There is no meaning in returning more information than that, oa-verify is meant to provide that level of abstraction to dependant applications.

In the cases from line 69 to 82, we are certain the token was not minted (regardless of which error it is), there is no error in those cases.

I was initially reluctant to return more information that true/false.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As for SERVER_ERROR, I can make the change to throw that one with a code.

@yehjxraymond yehjxraymond changed the base branch from master to feat/stricterVerification October 30, 2020 06:40
@yehjxraymond yehjxraymond force-pushed the feat/stricterVerification branch from ab85f21 to 5ba688d Compare October 30, 2020 06:46
@yehjxraymond yehjxraymond merged commit 3a7c552 into feat/stricterVerification Oct 30, 2020
@yehjxraymond yehjxraymond deleted the feat/strictTokenRegistryCheck branch October 30, 2020 06:59
yehjxraymond added a commit that referenced this pull request Nov 6, 2020
* feat: restrict token registry to fail on multiple issuers (#129)

* feat: restrict token registry to fail on multiple issuers

* feat: added reasons back

* feat: added server error

* feat: stricter document store verifier (#133)

* feat: stricter did signed document verifier (#134)

* feat: stricter did identity (#135)

* chore: refactored error handling

* feat: restricted didIdentityProof

* feat: stricter dns did identity (#136)

* feat: restricted dnsDid

* feat: stricter dnsTxt (#137)

* feat: aligning data.reason in individual fragments (#138)

* feat: aligning naming convention with files and modules (#139)

BREAKING CHANGE: Modules name changes and stricter verification rules
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants