sys design: api write
Gitea Actions Demo / Explore-Gitea-Actions (push) Failing after 41s Details

This commit is contained in:
Ladd Hoffman 2024-05-20 16:41:42 -05:00
parent 94778d711c
commit ee6730e13f
2 changed files with 39 additions and 6 deletions

View File

@ -2,6 +2,7 @@ const objectHash = require('object-hash');
const verifySignature = require('../verify-signature');
const { forum } = require('../db');
const read = require('./read');
const write = async ({
sender, authors, content, references, embeddedData, signature,
@ -27,6 +28,24 @@ const write = async ({
sender, authors, content, signature, embeddedData,
});
// Make sure a post with this hash has not already been written
let existingPost;
try {
existingPost = await read(hash);
// If this doesn't throw, it means a post with this hash was already written
} catch (e) {
if (e.status !== 404) {
throw e;
}
}
if (existingPost) {
const err = new Error();
err.status = 403;
err.message = `A post with hash ${hash} already exists`;
throw err;
}
// Store content
await forum.put(hash, data);

View File

@ -166,12 +166,26 @@ As outlined in the Rollup section above, we need to define processes for handlin
Parameters
| Name | Type | Description |
| --- | --- | --- |
| sender | Wallet address | |
| authors | Array of tuples: Wallet address, author weight |
| content | String |
| cit
| Name | Type |
| --- | --- |
| `sender` | Wallet address |
| `authors` | Array of tuples: (Wallet address, weight) |
| `content` | String |
| `references` | Array of tuples: (Post ID, weight) |
| `embeddedData` | Object |
| `signature` | Sender or author signature of `content` and `embeddedData` |
In order to protect the integrity of the off-chain Forum, the API should verify that the Post is signed by one of its authors, or by the sender. The reason for allowing the Post to be signed by the sender rather than by an author, is to support the use case of adding a Post on behalf of its author(s).
The API should compute a hash of all input parameters except for `references`, and use this hash as the key for storing the Post. The hash should also be returned to the caller.
The reason for excluding `references` from the hash, is to support the use case of importing Posts from an existing data source. If we included the references, then to import any Posts from an existing data source, we would have to import every referenced post, starting with the earliest, in order to compute the entire tree of references made by a given Post. By omitting references from the hash, it becomes possible to precompute the hash (a.k.a. ID) of referenced Posts that have not yet been imported.
The reason for excluding `references` from the signature, is to reduce the number of queries that must be made to an existing data source when importing a Post.
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
#### Read