sys design: api read
Gitea Actions Demo / Explore-Gitea-Actions (push) Failing after 27s
Details
Gitea Actions Demo / Explore-Gitea-Actions (push) Failing after 27s
Details
This commit is contained in:
parent
ee6730e13f
commit
5a407efd2d
|
@ -185,10 +185,14 @@ The reason for excluding `references` from the signature, is to reduce the numbe
|
|||
|
||||
Note that because `references` is not included in the hash, there is a replay attack vulnerability. Someone could read an existing Post, modify the `references`, and write the modified Post back to the API. The signatures will still be valid even though the references have changed, and the new references will overwrite the previous references. Note that this would only affect the off-chain record of the Post's references. If the Post is published to the on-chain Forum, it is not subject to such modification, as a Post with a given ID can only be added once. To mitigate this vulnerabliity in the off-chain Forum, we should reject a write attempt if a Post with the given ID already exists.
|
||||
|
||||
When
|
||||
When a Post is written, the Forum API should send an `io.dgov.forum.post` event to the Matrix room. Forum API nodes should listen for events of this type. When an `io.dgov.forum.post` event is received, each of the other Forum API nodes should write the Post to storage just just as they would if the `write` endpoint were called directly.
|
||||
|
||||
Each Forum API node should keep track of the most recent `io.dgov.forum.post` event received. On startup, each Forum API node should query the Matrix Homeserver for any newer `io.dgov.forum.post` events.
|
||||
|
||||
#### Read
|
||||
|
||||
The `read` endpoint should accept a Post ID argument, and retrieve the corresponding Post from storage. Before sending the Post to the caller, the Forum API should verify the hash and signature, to ensure the integrity of the record.
|
||||
|
||||
## Automated Staking
|
||||
|
||||
### Validation Pool
|
||||
|
|
Loading…
Reference in New Issue