feat(consortium-static): new consortium plugin #3471
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
eduv09
requested review from
petermetz,
takeutak,
izuru0,
jagpreetsinghsasan,
VRamakrishna,
sandeepnRES and
outSH
as code owners
petermetz
requested changes
Aug 12, 2024
There was a problem hiding this comment.
@eduv09 Looks like a high quality PR, thank you very much! I have some nit-picks in the comments above and a couple requests here:
- Remove the changelog file, it doesn't make sense to have it in a new package - it gets auto-generated when we issue a release.
- Add a CI job in ci.yaml that runs the Jest tests so that it can be verified to keep working after each PR. Note that the github action versions to use are changing so make sure to use the up to date versions as shown in this otherwise unrelated PR: https://github.com/hyperledger/cacti/pull/3478
...cti-plugin-consortium-static/src/main/typescript/consortium/process-broadcast-endpoint-v1.ts
Outdated
Show resolved
Hide resolved
...cti-plugin-consortium-static/src/main/typescript/consortium/process-broadcast-endpoint-v1.ts
Outdated
Show resolved
Hide resolved
...ges/cacti-plugin-consortium-static/src/main/typescript/repository/new-consortium-provider.ts
Outdated
Show resolved
Hide resolved
...s/cacti-plugin-consortium-static/src/main/typescript/repository/new-consortium-repository.ts
Outdated
Show resolved
Hide resolved
packages/cacti-plugin-consortium-static/src/main/typescript/plugin-consortium-static.ts
Outdated
Show resolved
Hide resolved
|
@eduv09 One more thing: if you run
|
RafaelAPB
reviewed
Aug 13, 2024
packages/cacti-plugin-consortium-static/src/main/json/openapi.json
Outdated
Show resolved
Hide resolved
packages/cacti-plugin-consortium-static/src/main/typescript/utils.ts
Outdated
Show resolved
Hide resolved
packages/cacti-plugin-consortium-static/src/main/typescript/plugin-consortium-static.ts
Show resolved
Hide resolved
packages/cacti-plugin-consortium-static/src/main/typescript/plugin-consortium-static.ts
Outdated
Show resolved
Hide resolved
packages/cacti-plugin-consortium-static/src/main/typescript/policy-model/polity-item.ts
Show resolved
Hide resolved
eduv09
force-pushed
the
cacti-consortium-update
branch
3 times, most recently
from
c75f8b2 to
1eb0da1
Compare
|
@RafaelAPB @petermetz I think I addressed all of the changes you requested. Let me know if I missed something, or of any other recommendations. Thank you ! |
|
@eduv09 please rebase and fix any conflicts or errors |
eduv09
force-pushed
the
cacti-consortium-update
branch
2 times, most recently
from
cb313ff to
0388f09
Compare
|
@RafaelAPB Done |
|
LGTM, let's wait for @petermetz 's re-review. Cheers |
petermetz
approved these changes
Aug 26, 2024
There was a problem hiding this comment.
@eduv09 @RafaelAPB LGTM, thank you for addressing my nit-picks!
For the JWSGeneral casting question, please see my analysis here (short answer, let's merge this as is and I'll work on fixing the casting) => https://github.com/hyperledger/cacti/pull/3471#discussion_r1731894747
One more thing: If you hit the re-request review button it will automatically land back in my PR review queue (which I try to check daily even when I don't have time to process discord messages) so I recommend hitting that every time a PR I reviewed is ready for some more attention. Tagging me on Discord and on GitHub also helps so I recommend you also keep doing that of course!
petermetz
referenced
this pull request
in petermetz/cacti
Aug 27, 2024
1. createAjvTypeGuard<T>() is the lower level utility which can be used
to construct the more convenient, higher level type predicates/type guards
such as createIsJwsGeneralTypeGuard() which uses createAjvTypeGuard<JwsGeneral>
under the hood.
2. This commit is also meant to be establishing a larger, more generic
pattern of us being able to create type guards out of the Open API specs
in a convenient way instead of having to write the validation code by hand.
An example usage of the new createAjvTypeGuard<T>() utility is the
createIsJwsGeneralTypeGuard() function itself.
An example usage of the new createIsJwsGeneralTypeGuard() can be found
in packages/cactus-plugin-consortium-manual/src/main/typescript/plugin-consortium-manual.ts
The code documentation contains examples as well for maximum discoverabilty
and I'll also include it here:
```typescript
import { JWSGeneral } from "@hyperledger/cactus-core-api";
import { createIsJwsGeneralTypeGuard } from "@hyperledger/cactus-core-api";
export class PluginConsortiumManual {
private readonly isJwsGeneral: (x: unknown) => x is JWSGeneral;
constructor() {
// Creating the type-guard function is relatively costly due to the Ajv schema
// compilation that needs to happen as part of it so it is good practice to
// cache the type-guard function as much as possible, for examle by adding it
// as a class member on a long-lived object such as a plugin instance which is
// expected to match the life-cycle of the API server NodeJS process itself.
// The specific anti-pattern would be to create a new type-guard function
// for each request received by a plugin as this would affect performance
// negatively.
this.isJwsGeneral = createIsJwsGeneralTypeGuard();
}
public async getNodeJws(): Promise<JWSGeneral> {
// rest of the implementation that produces a JWS ...
const jws = await joseGeneralSign.sign();
if (!this.isJwsGeneral(jws)) {
throw new TypeError("Jose GeneralSign.sign() gave non-JWSGeneral type");
}
return jws;
}
}
```
Relevant discussion took place here:
https://github.com/hyperledger/cacti/pull/3471#discussion_r1731894747
Signed-off-by: Peter Somogyvari <[email protected]>
5 tasks
petermetz
referenced
this pull request
in petermetz/cacti
Aug 27, 2024
1. createAjvTypeGuard<T>() is the lower level utility which can be used
to construct the more convenient, higher level type predicates/type guards
such as createIsJwsGeneralTypeGuard() which uses createAjvTypeGuard<JwsGeneral>
under the hood.
2. This commit is also meant to be establishing a larger, more generic
pattern of us being able to create type guards out of the Open API specs
in a convenient way instead of having to write the validation code by hand.
An example usage of the new createAjvTypeGuard<T>() utility is the
createIsJwsGeneralTypeGuard() function itself.
An example usage of the new createIsJwsGeneralTypeGuard() can be found
in packages/cactus-plugin-consortium-manual/src/main/typescript/plugin-consortium-manual.ts
The code documentation contains examples as well for maximum discoverabilty
and I'll also include it here:
```typescript
import { JWSGeneral } from "@hyperledger/cactus-core-api";
import { createIsJwsGeneralTypeGuard } from "@hyperledger/cactus-core-api";
export class PluginConsortiumManual {
private readonly isJwsGeneral: (x: unknown) => x is JWSGeneral;
constructor() {
// Creating the type-guard function is relatively costly due to the Ajv schema
// compilation that needs to happen as part of it so it is good practice to
// cache the type-guard function as much as possible, for examle by adding it
// as a class member on a long-lived object such as a plugin instance which is
// expected to match the life-cycle of the API server NodeJS process itself.
// The specific anti-pattern would be to create a new type-guard function
// for each request received by a plugin as this would affect performance
// negatively.
this.isJwsGeneral = createIsJwsGeneralTypeGuard();
}
public async getNodeJws(): Promise<JWSGeneral> {
// rest of the implementation that produces a JWS ...
const jws = await joseGeneralSign.sign();
if (!this.isJwsGeneral(jws)) {
throw new TypeError("Jose GeneralSign.sign() gave non-JWSGeneral type");
}
return jws;
}
}
```
Relevant discussion took place here:
https://github.com/hyperledger/cacti/pull/3471#discussion_r1731894747
Signed-off-by: Peter Somogyvari <[email protected]>
eduv09
force-pushed
the
cacti-consortium-update
branch
from
0388f09 to
55c186b
Compare
* New plugin consortium-static, based on consortium-manual. Long story short, the plugin allows for the addition of Cacti Nodes to consortium at runtime. New node entities must belong to one of the consortium entities (organizations) that were specified on consortium creation. So it allows to add new nodes 'CactusNode', but not new 'ConsortiumMember' entities. * New feature: add CactusNode to consortium at runtime The code is based on the plugin-consortium-manual, with the new features built on top of it. The process of adding a new node is conducted as follows: 1. The new node forges a request with information about itself and sends it to any Node in the consortium 2. The receiver verifies the request, and if it is approved, broadcasts it to the rest of the consortium Nodes. 3. Each node verifies the same request, and adds the new node to the consortium database. At the same time, the receiver node from point 2 sends the consortium data to the new node, who updates it's database. * Includes a new policy model The package includes a policy model, which was developed based on the ideas of the Policy Core Information Model [RFC3060](https://www.rfc-editor.org/rfc/rfc3060) . The idea was to introduce the idea of a multi-purpose policy framework that can be leveraged by other packages in cacti. Signed-off-by: eduv09 <[email protected]>
eduv09
force-pushed
the
cacti-consortium-update
branch
from
55c186b to
977c816
Compare
|
@petermetz fixed the CI workflow issue. I think it's good to go. Thank you for the assist 🙏 |
RafaelAPB
approved these changes
Aug 28, 2024
petermetz
approved these changes
Aug 28, 2024
@eduv09 You got it! Thank you very much for the contribution! |
petermetz
referenced
this pull request
in petermetz/cacti
Aug 30, 2024
1. createAjvTypeGuard<T>() is the lower level utility which can be used
to construct the more convenient, higher level type predicates/type guards
such as createIsJwsGeneralTypeGuard() which uses createAjvTypeGuard<JwsGeneral>
under the hood.
2. This commit is also meant to be establishing a larger, more generic
pattern of us being able to create type guards out of the Open API specs
in a convenient way instead of having to write the validation code by hand.
An example usage of the new createAjvTypeGuard<T>() utility is the
createIsJwsGeneralTypeGuard() function itself.
An example usage of the new createIsJwsGeneralTypeGuard() can be found
in packages/cactus-plugin-consortium-manual/src/main/typescript/plugin-consortium-manual.ts
The code documentation contains examples as well for maximum discoverabilty
and I'll also include it here:
```typescript
import { JWSGeneral } from "@hyperledger/cactus-core-api";
import { createIsJwsGeneralTypeGuard } from "@hyperledger/cactus-core-api";
export class PluginConsortiumManual {
private readonly isJwsGeneral: (x: unknown) => x is JWSGeneral;
constructor() {
// Creating the type-guard function is relatively costly due to the Ajv schema
// compilation that needs to happen as part of it so it is good practice to
// cache the type-guard function as much as possible, for examle by adding it
// as a class member on a long-lived object such as a plugin instance which is
// expected to match the life-cycle of the API server NodeJS process itself.
// The specific anti-pattern would be to create a new type-guard function
// for each request received by a plugin as this would affect performance
// negatively.
this.isJwsGeneral = createIsJwsGeneralTypeGuard();
}
public async getNodeJws(): Promise<JWSGeneral> {
// rest of the implementation that produces a JWS ...
const jws = await joseGeneralSign.sign();
if (!this.isJwsGeneral(jws)) {
throw new TypeError("Jose GeneralSign.sign() gave non-JWSGeneral type");
}
return jws;
}
}
```
Relevant discussion took place here:
https://github.com/hyperledger/cacti/pull/3471#discussion_r1731894747
Signed-off-by: Peter Somogyvari <[email protected]>
petermetz
referenced
this pull request
Sep 2, 2024
1. createAjvTypeGuard<T>() is the lower level utility which can be used
to construct the more convenient, higher level type predicates/type guards
such as createIsJwsGeneralTypeGuard() which uses createAjvTypeGuard<JwsGeneral>
under the hood.
2. This commit is also meant to be establishing a larger, more generic
pattern of us being able to create type guards out of the Open API specs
in a convenient way instead of having to write the validation code by hand.
An example usage of the new createAjvTypeGuard<T>() utility is the
createIsJwsGeneralTypeGuard() function itself.
An example usage of the new createIsJwsGeneralTypeGuard() can be found
in packages/cactus-plugin-consortium-manual/src/main/typescript/plugin-consortium-manual.ts
The code documentation contains examples as well for maximum discoverabilty
and I'll also include it here:
```typescript
import { JWSGeneral } from "@hyperledger/cactus-core-api";
import { createIsJwsGeneralTypeGuard } from "@hyperledger/cactus-core-api";
export class PluginConsortiumManual {
private readonly isJwsGeneral: (x: unknown) => x is JWSGeneral;
constructor() {
// Creating the type-guard function is relatively costly due to the Ajv schema
// compilation that needs to happen as part of it so it is good practice to
// cache the type-guard function as much as possible, for examle by adding it
// as a class member on a long-lived object such as a plugin instance which is
// expected to match the life-cycle of the API server NodeJS process itself.
// The specific anti-pattern would be to create a new type-guard function
// for each request received by a plugin as this would affect performance
// negatively.
this.isJwsGeneral = createIsJwsGeneralTypeGuard();
}
public async getNodeJws(): Promise<JWSGeneral> {
// rest of the implementation that produces a JWS ...
const jws = await joseGeneralSign.sign();
if (!this.isJwsGeneral(jws)) {
throw new TypeError("Jose GeneralSign.sign() gave non-JWSGeneral type");
}
return jws;
}
}
```
Relevant discussion took place here:
https://github.com/hyperledger/cacti/pull/3471#discussion_r1731894747
Signed-off-by: Peter Somogyvari <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New plugin consortium-static, based on consortium-manual.
Long story short, the plugin allows for the addition of Cacti Nodes to consortium at runtime. New node entities must belong to one of the consortium entities (organizations) that were specified on consortium creation. So it allows to add new nodes 'CactusNode', but not new 'ConsortiumMember' entities.
New feature: add CactusNode to consortium at runtime
The code is based on the plugin-consortium-manual, with the new features built on top of it. The process of adding a new node is conducted as follows:
Includes a new policy model
The package includes a policy model, which was developed based on the ideas of the Policy Core Information Model RFC3060 . The idea was to introduce the idea of a multi-purpose policy framework that can be leveraged by other packages in cacti.