feat: Enforce no unexpected fields in events #355
Conversation
stbrody
force-pushed
the
disallow-unexpected-metadata
branch
from
a626858
to
7efcd7d
Compare
| // Use self.len() here when we have cid@0.10 | ||
| let buf = Vec::new(); | ||
| let mut writer = std::io::BufWriter::new(buf); | ||
| self.write(&mut writer)?; | ||
| Ok(writer.into_inner()?) | ||
| // safe to unwrap because self.write should never fail. |
There was a problem hiding this comment.
@nathanielc let me know if this is what you had in mind or if there's more I should do to handle this error.
| @@ -6,6 +6,7 @@ use std::collections::BTreeMap; | |||
|
|
|||
| /// A signed event payload. | |||
| #[derive(Debug, Serialize, Deserialize)] | |||
| #[serde(deny_unknown_fields)] | |||
There was a problem hiding this comment.
this is the only one I'm not sure of. I believe this struct represents the JWS envelope and I don't actually know if it's safe to assume that that doesn't have extra fields. I think I'm leaning towards removing the deny_unknown_fields tag on this struct since the JWS envelope format isn't really a part of the Ceramic protocol spec so feels like maybe a place where we should be looser in what we accept. Curious for other's thoughts here.
There was a problem hiding this comment.
Wait, actually I'm confused. There's also the SignedEvent struct that has a Jws struct:
@dbcfd - what's the relationship between this signed::Payload struct and the SignedEvent struct? Are they both used or can one be deleted?
There was a problem hiding this comment.
SignedEvent is what js-ceramic requires, hence it is in ext. signed::Payload is what comes from js-ceramic when it is written to a car file.
|
Note I have this test of sending extra fields in ceramic-tests: 3box/ceramic-tests#129. Not sure how to run that test against a version of rust-ceramic from this branch... |
|
closing. Event changes will be included in #357. Adding the serde directive to restrict unexpected fields will come in a follow-up PR |
This PR temporarily removes the recently-added Builder structs, so as to focus first on getting the underlying Event types right and ensure all fields in the Events are specified explicitly. Once this is set we can add back the builders in a way that preserves type safety better and makes it impossible to build invalid events.